Résumé

  • RFC 1446 soumettait chaque message authentifié à deux épreuves distinctes : la vérification d’un condensat MD5 fondé sur un secret partagé, puis un contrôle de durée de vie destiné à écarter les messages trop anciens.
  • La valeur de partyAuthClock ne devait jamais diminuer sous une même clé privée. Un recul aurait rouvert une tranche de temps déjà close ; d’anciens messages pouvaient alors redevenir admissibles sans que leur condensat ait été falsifié.
  • La continuité de sécurité reposait donc sur une époque faite d’une identité, d’une génération de clé et d’un temps monotone. RFC 3414 adoptera plus tard le triplet moteur faisant autorité, compteur de démarrages et temps depuis le démarrage, sans confondre authenticité cryptographique et fraîcheur.

Un message expiré qui redevient jeune

La panne n’a besoin d’être ni spectaculaire ni malveillante. Un équipement s’éteint, perd la valeur la plus récente de son horloge d’authentification, puis redémarre avec une sauvegarde plus ancienne. Sa clé partagée, elle, a survécu. Sur le papier, chaque donnée semble familière : la clé est la bonne, l’identité est connue, l’horloge contient une valeur plausible. C’est leur combinaison qui est dangereuse.

Supposons qu’un message ait été émis à l’instant logique 80 000 et que la durée de vie admise soit de 300 secondes. Lorsque le destinataire situe la source au-delà de 80 300, la copie enregistrée est trop vieille. Si, après redémarrage, sa notion locale de cette horloge revient à 79 900, la même copie rentre à nouveau dans la fenêtre. Aucun octet n’a changé. Le condensat peut rester exact. C’est le destinataire qui a déplacé la limite du passé.

RFC 1446 reconnaissait ainsi que l’anti-rejeu n’est pas une propriété contenue dans un paquet. Il dépend d’un état conservé par celui qui décide. Une preuve d’intégrité peut traverser le temps intact ; sans mémoire monotone, elle ne dit pas si le message appartient à l’échange présent ou à une séquence déjà consommée.

Le texte transformait cette observation en règle d’exploitation : tant qu’une clé privée d’authentification reste la même, l’horloge de la partie ne décroît pas. Si une diminution devient nécessaire, la clé change simultanément. L’ancienne clé ne doit pas reconnaître les messages de la tranche rouverte.

Deux refus possibles avant toute opération

Publié en avril 1993 et désormais classé Historic, RFC 1446 définissait pour SNMPv2 un protocole d’authentification et un protocole de confidentialité. Son profil interopérable d’authentification utilisait MD5 et 16 octets de matériau secret pour une partie associée à v2md5AuthProtocol.

À l’émission, le secret occupait provisoirement le champ réservé au condensat. Le message sous cette forme était sérialisé et haché ; le résultat de 128 bits remplaçait ensuite le secret dans le paquet transmis. À la réception, le destinataire retirait le condensat reçu, reconstruisait la forme authentifiée avec sa propre copie de la clé, recalculait puis comparait. Une divergence alimentait snmpStatsWrongDigestValues et conduisait au rejet.

Cette mécanique vérifiait une relation entre les octets et le secret connu localement. Elle ne décidait pas seule de la fraîcheur. Le destinataire consultait aussi, pour la partie source, son horloge enregistrée et la durée de vie configurée. Le message était hors délai lorsque :

authSrcTimestamp + durée de vie < horloge locale d’authentification

Dans ce cas, snmpStatsNotInLifetimes augmentait et le message était déclaré non authentique au sens du traitement. Le vocabulaire peut troubler : le condensat pouvait correspondre, mais le message échouait à une autre condition de l’authentification complète.

Il faut garder cette distinction dans les traces. Un calcul de condensat réussi établit que les octets observés satisfaisaient le test cryptographique du récepteur avec une clé déterminée. Une comparaison temporelle établit qu’ils se situaient ou non dans sa fenêtre. Aucun de ces constats ne suffit à prouver que la politique d’accès autorisait l’action, que l’agent l’a exécutée, que l’équipement a changé d’état ou que ce changement a survécu à un autre redémarrage.

La durée de vie n’était pas une constante naturelle

Les messages transportaient des horodatages d’authentification pour la source et la destination, avec une granularité d’une seconde. La durée de vie était un plafond administratif appliqué au retard acceptable. Le RFC recommandait de la réduire autant que le permettaient la précision des horloges, le temps d’aller-retour et la fréquence des vérifications.

Cette valeur arbitrait entre deux pertes. Trop courte, elle rejetait des échanges légitimes ralentis ou désynchronisés. Trop longue, elle maintenait plus longtemps la valeur d’usage d’une capture. Augmenter la fenêtre pour faire disparaître des erreurs n’était donc pas un réglage neutre de disponibilité ; c’était une décision de sécurité qui reculait la frontière de péremption.

Un message dans la fenêtre n’était pas pour autant unique. Plusieurs copies identiques pouvaient rester recevables. Pour les opérations modifiant un état, RFC 1446 conseillait d’attendre un accusé positif ou l’expiration de l’intervalle avant d’envoyer la suivante. Le protocole reconnaissait les limites de sa garantie : le temps bornait le rejeu, il ne fournissait pas à lui seul l’ordre total d’un journal transactionnel.

Après les contrôles temporel et cryptographique venait la politique d’accès. Ce n’est que lorsqu’un accès était permis que des horodatages authentifiés supérieurs pouvaient faire progresser sélectivement les notions locales des horloges. La réception, l’intégrité, la fraîcheur, l’autorisation et l’effet restaient des étapes successives, chacune susceptible de produire un résultat différent.

Une horloge et une clé formaient une seule époque

Le couplage prescrit devient clair lorsqu’on examine ce qui survit au recul. Avec l’ancienne clé seule, le destinataire reconnaît encore l’authenticité des anciens condensats. Avec l’ancienne plage temporelle rouverte, il juge encore leurs horodatages assez récents. Conserver les deux restaure donc exactement les deux conditions dont une capture avait besoin.

Une nouvelle clé rompt cette continuité. Les horodatages anciens peuvent redevenir numériquement proches, mais les condensats calculés dans l’époque précédente ne correspondent plus. Le changement simultané ne « corrige » pas le temps ; il annonce que la même valeur d’horloge n’a plus la même identité cryptographique.

RFC 1447 inscrivait cette règle dans la définition de partyAuthClock : la valeur ne pouvait être diminuée sans modification simultanée de la clé privée d’authentification. partyAuthLifetime exposait la durée de vie en secondes. Le modèle d’information rendait donc administrable une relation de sécurité, pas un simple compteur.

Il rendait aussi visible la complexité de la relève des secrets. Décider une nouvelle clé, envoyer la requête, la faire recevoir, obtenir son adoption, informer les autres stations responsables puis retirer l’ancienne clé sont des événements distincts. Pendant cet intervalle, une station peut devoir conserver les deux secrets, y compris au travers de son propre redémarrage. Une requête réussie côté émetteur ne prouve pas l’état final chez toutes les parties.

Se synchroniser sans faire confiance au premier nombre

Le fonctionnement supposait des horloges grossièrement synchronisées et au moins une station de gestion responsable de la distribution des secrets et de la coordination temporelle. Quand aucune clé ne changeait, la méthode ordinaire consistait à faire avancer la notion la plus lente vers la plus rapide. Elle évitait de ramener en arrière la valeur la plus haute sous le même secret.

Le RFC prévoyait pourtant un démarrage où le gestionnaire ignorait si sa propre notion du temps concordait avec celle de l’agent. Il pouvait d’abord lire les valeurs sans authentification. Ce premier résultat servait de candidat, non de preuve. Après l’avoir adopté, il devait effectuer une lecture authentifiée afin de vérifier la valeur.

La séquence est remarquable parce qu’elle ne maquille pas la faiblesse de sa première étape. Une observation non authentifiée aide à retrouver un point de départ ; elle ne devient pas digne de confiance par simple copie dans une base locale. La confirmation suivante possède une provenance différente. Les conserver séparément permet de montrer comment la confiance a été acquise.

Plusieurs stations responsables créaient un autre problème de gouvernance. Elles pouvaient diverger sur la génération de clé ou sur la valeur courante d’une horloge. Une transition correcte pour l’une pouvait couper l’autre. Le standard définissait les invariants, mais l’organisation devait encore déterminer qui avait le droit d’ouvrir une nouvelle époque et comment la décision était partagée.

La mémoire devait résister à l’arrêt

Un mécanisme anti-rejeu qui oublie à chaque coupure transforme le redémarrage en outil de rejeu. RFC 1446 demandait donc des représentations non volatiles et incorruptibles de l’identité des parties, de leur horloge d’authentification, de la clé privée d’authentification et de la clé privée de confidentialité. La durée de vie devait recevoir une protection comparable lorsque c’était possible.

L’horloge pouvait être entretenue par une source secourue sur batterie. Une autre mise en œuvre pouvait enregistrer périodiquement un point en mémoire non volatile, puis ajouter au redémarrage une marge suffisante pour dépasser toute valeur plausible avant la panne. Les moyens différaient ; l’obligation de ne pas revenir dans une époque ancienne demeurait.

Si un agent restait arrêté jusqu’à ce qu’une horloge atteigne sa valeur maximale, celle-ci se figeait au maximum. La seule requête de gestion authentifiée qu’il convenait alors d’envoyer devait changer au moins l’horloge et la clé. Le maximum marquait la fin de l’époque, pas une invitation à remettre le compteur à zéro.

La perte complète des paramètres protégés entraînait une réponse encore plus prudente : générer des valeurs aléatoires de remplacement, puis exiger une redistribution manuelle. Continuer avec une continuité imaginée aurait amélioré la disponibilité au prix d’un passé impossible à vérifier.

Du temps continu au numéro de démarrage

RFC 3414 réorganisa plus tard la fraîcheur autour du moteur SNMP faisant autorité. snmpEngineID désignait ce moteur, snmpEngineBoots comptait les démarrages ou réinitialisations et snmpEngineTime mesurait les secondes écoulées dans le démarrage courant. L’identifiant et le compteur de démarrages devaient être non volatils. Le temps pouvait repartir de zéro dès lors que le compteur avançait.

La nouvelle représentation remplaçait un long temps continu par une paire époque-compteur. Un destinataire faisant autorité rejetait un compteur de démarrages différent ou un temps situé hors de la fenêtre fixée à 150 secondes. Le condensat et la fraîcheur restaient néanmoins deux contrôles. Une valeur d’authentification juste ne transportait pas avec elle la preuve d’appartenir au démarrage actuel.

Si le compteur récent ne pouvait plus être déterminé, le moteur le bloquait à sa valeur maximale. Les messages authentifiés échouaient alors au contrôle temporel jusqu’à ce qu’une intervention manuelle crée une nouvelle identité de moteur ou de nouveaux secrets utilisateur. Là encore, l’arrêt explicite valait mieux qu’une continuité inventée.

RFC 3414 n’est pas le successeur direct de RFC 1446 ; des modèles intermédiaires appartiennent à la généalogie. La comparaison porte sur l’architecture. Le premier liait le recul d’une horloge de partie à une nouvelle clé. Le second autorisait le temps intra-démarrage à repartir grâce à un compteur durable et une identité de moteur. Tous deux exigeaient que le récepteur sache non seulement « ce message correspond-il au secret ? », mais aussi « de quelle histoire vient-il ? ».

Sources