Résumé

  • Le mode de transition de RFC 5304 peut émettre HMAC-MD5 sans le vérifier à la réception ; un système non compatible peut accepter le type. Voir un MAC sur le fil ne prouve pas l’application du contrôle.
  • Plusieurs mots de passe, les règles propres aux purges et la reprise après rotation créent des décisions distinctes. Même un PDU authentifié ne prouve ni la justesse de l’annonce, ni la convergence, ni la livraison.

Deux paquets identiques, deux politiques de réception

RFC 5304 utilise le TLV d’authentification IS-IS, de type 10, et attribue la valeur 54 à HMAC-MD5. Le calcul met à zéro la valeur d’authentification ; pour les LSP, le checksum et la durée de vie restante sont également neutralisés. Cette recette permet à un récepteur de reproduire un digest. Elle ne force pas chaque récepteur à le faire.

Le texte autorise un mode de transition : inclure l’information HMAC-MD5 dans les PDU sortants, mais ne pas vérifier celle des PDU entrants. L’objectif est un déploiement progressif. Le résultat est un intervalle pendant lequel la trace réseau ressemble à l’état final, alors que la porte d’entrée applique encore l’ancienne politique.

Une autre clause autorise une implémentation qui ne connaît pas HMAC-MD5 à accepter un PDU portant ce type. Le champ ne peut pas imposer une capacité absente. L’émetteur prouve qu’il a produit une structure ; il ne prouve pas ce que son voisin en a fait.

Pour une implémentation qui réalise HMAC-MD5, la règle devient ferme : une valeur incorrecte doit entraîner le rejet. L’audit doit donc relier plusieurs faits : algorithme disponible, vérification activée, jeu de clés applicable, résultat du calcul, décision d’acceptation et modification d’état. Sans cette chaîne, « authentifié » reste une description ambiguë.

RFC 5304 date de 2008, relève du Standards Track et remplace RFC 3567. Son analyse historique de HMAC-MD5 n’est pas une recommandation cryptographique contemporaine. L’intérêt présent est la logique d’application du contrôle.

Le jeu de clés agrandit temporairement l’autorité

Les clés n’ont déjà pas un seul périmètre. Les SNP de niveau 1 utilisent la chaîne d’aire, ceux de niveau 2 la chaîne de domaine, et les IIH une chaîne de lien qui peut différer de celle des LSP. Une case « authentification IS-IS » ne dit donc pas quelle surface dépend de quel secret.

Lors d’une rotation, le récepteur peut tester plusieurs mots de passe. La continuité s’améliore, mais une acceptation n’indique plus quelle clé a réussi. L’ancienne clé peut rester valide après l’instant où l’organisation la croit retirée. Il faut connaître l’ensemble candidat, l’ordre de test, les dates d’activation et de retrait, le périmètre et la preuve que la période de chevauchement est finie.

Ce chevauchement n’est pas une faiblesse mathématique ; c’est une extension volontaire de l’autorité. Une exception sans date d’expiration transforme un outil de migration en confiance permanente supplémentaire. RFC 5310 introduira plus tard des Key ID et des associations HMAC-SHA, rendant la sélection plus explicite. Même un identifiant ne prouve toutefois pas que la bonne politique a été installée sur chaque récepteur.

Une purge n’est pas une annonce ordinaire

Une purge cherche à retirer un LSP en plaçant sa durée de vie à zéro. RFC 5304 lui impose donc une forme restreinte. Un routeur compatible qui lance la purge retire le corps du LSP et ajoute le TLV d’authentification. Il ne doit pas accepter une purge non authentifiée ni une purge contenant d’autres TLV.

La menace visée est simple : copier un LSP légitime, mettre Remaining Lifetime à zéro, puis l’inonder sans connaître le secret. La forme spéciale sépare le pouvoir de supprimer du simple pouvoir de rejouer une annonce reçue.

Le journal doit refléter ce statut. « Digest valide » n’est pas encore « purge autorisée ». Il faut la forme dépouillée, l’absence de TLV interdits, la vérification réussie sous la bonne règle et l’effet observé. Le rejet d’une purge portant encore son corps n’est pas un échec d’interopérabilité ; il peut être l’application exacte de la frontière.

La rotation peut enfermer le routeur derrière son ancien LSP

Après changement de mot de passe, un redémarrage peut faire repartir le numéro de séquence local à 1 sous la nouvelle clé. Les voisins possèdent encore l’ancien LSP, avec un numéro supérieur, et rejettent le nouveau. Le routeur devrait apprendre ce numéro supérieur par le retour de son propre LSP.

Mais ce retour est signé avec l’ancien mot de passe, désormais refusé. Le routeur ne peut plus authentifier l’état qu’il avait lui-même créé et ne peut pas reprendre normalement son espace de séquence. Sans autre mesure, il attend l’expiration de l’ancien LSP chez les voisins.

RFC 5304 propose de regarder un cas très borné : un LSP entrant échoue à l’authentification, porte le System ID local et un numéro supérieur. Le processus peut alors relever son numéro et réémettre sous la nouvelle clé. Un adversaire pouvant provoquer le même signal, le RFC recommande un compteur.

Il ne s’agit pas d’accepter le contenu non authentifié. Une coordonnée non fiable sert à réparer un compteur local, puis un LSP neuf est généré. Cette exception doit néanmoins être visible, car elle influence l’autorité de séquence.

Ce que le HMAC ne garantit pas

Le document présente une hausse du coût d’attaque par rapport au mot de passe en clair, pas une sécurité parfaite. Il ne supprime pas le rejeu par lui-même, même si IS-IS écarte souvent les informations anciennes. Il ne supprime pas le déni de service et ne protège pas contre un routeur compromis, défaillant ou mal configuré.

Un HMAC valide indique qu’un détenteur d’un secret admis a produit le message couvert. Il ne dit pas que la topologie est vraie, que ce détenteur avait mandat pour ce changement précis, que tous les récepteurs suivent la même liste de clés, ni que le trafic passe. La qualité dépend aussi de l’algorithme, de la clé, de l’implémentation et de la confidentialité chez tous les participants.

Limites de l’analyse

Le présent article ne recommande pas HMAC-MD5 pour une nouvelle architecture et ne déduit aucun état actuel. RFC 5310 et les recommandations plus récentes doivent guider les choix contemporains. Vérifier un réseau exige versions, configurations, compteurs de rejet, clé sélectionnée, calendrier de rotation, journaux de purge, LSDB et plan de données.

La conclusion reste étroite : champ présent, capacité implémentée, vérification active, clé acceptée, règle particulière du PDU et effet de routage sont six faits différents. Seul le récepteur peut fournir le reçu des portes les plus importantes.

Sources