Résumé

  • Une clé conservée par le pair peut rester dans sa période d’usage alors qu’un redémarrage ou une récupération de mémoire a déjà vidé le cache de l’authentificateur.
  • La RFC 5247 ne confie pas la réparation à l’horloge : elle demande une resynchronisation protégée lorsque c’est possible, sinon une nouvelle authentification capable de recréer l’autorité perdue.

Deux vérités locales, aucun état commun

À 18 h 42, le terminal possède encore un contexte EAP. Son compteur local annonce onze minutes avant expiration. Le point d’accès, redémarré après une opération de maintenance, ne possède plus la ligne correspondante. Le terminal tente la voie rapide ; le réseau ne reconnaît pas la clé.

La tentation consiste à chercher le composant fautif. Pourtant, aucun des deux états n’est nécessairement faux. Une échéance définit la limite d’utilisation d’un objet présent. Elle ne contraint pas une autre machine à conserver cet objet jusqu’à la même seconde. Une entrée peut être valide et absente, ou présente et déjà interdite par une politique locale.

La RFC 5247 nomme exactement cette situation dans les exigences du protocole d’association sécurisée. Le pair ou l’authentificateur peut redémarrer, récupérer des ressources et effacer tout ou partie du cache. La négociation d’une durée ne peut donc pas garantir la synchronisation. Le pair peut même ignorer l’absence distante jusqu’à sa première tentative d’usage.

Cette précision transforme la manière de lire un voyant vert. « Non expirée » n’est pas une observation distribuée. C’est une assertion locale sous condition d’existence.

La chaîne EAP comporte plusieurs autorités

Le cadre distingue l’échange EAP avec le serveur, le transport AAA vers l’authentificateur et le protocole de phase 2 entre pair et authentificateur. Une méthode EAP peut produire un MSK et un EMSK. Le système AAA peut transporter du matériel et des paramètres d’autorisation. Le protocole d’association sécurisée doit ensuite identifier les parties, sélectionner la bonne clé, prouver la possession et produire des clés transitoires pour le trafic.

Chaque étape ferme une question. Aucune n’hérite automatiquement de toutes les réponses précédentes. Un succès EAP n’active pas une clé de trafic. La réception d’un MSK par un authentificateur ne prouve pas qu’il le conservera. Une preuve de possession réussie ne garantit pas qu’une application aval répondra.

Le cache est un raccourci dans cette chaîne, pas une nouvelle source d’autorité. Il permet de réutiliser un état dérivé auparavant. Au moment de la reprise, il faut encore établir que les deux extrémités possèdent le même état nommé, dans le même périmètre, et qu’elles savent en tirer des clés de session fraîches.

Pourquoi le nom de la clé compte

Un même pair et un même authentificateur peuvent partager plusieurs ensembles de clés. Une recherche par identité ne suffit donc pas à désigner sans ambiguïté le contexte retenu. La RFC 5247 impose au protocole d’association de nommer explicitement les clés utilisées dans la preuve de possession.

Ce nom ne doit pas devenir une preuve par lui-même. Il sélectionne le candidat. La preuve protégée établit ensuite que les parties possèdent effectivement le matériel associé. Des nonces ou compteurs contribuent à produire de nouvelles clés transitoires, afin que la conservation du matériau EAP n’entraîne pas la répétition des mêmes clés de trafic.

Le journal opérationnel devrait respecter cet ordre : nom proposé, correspondance locale, réponse distante, preuve commune, entrées fraîches, dérivation, activation, premier paquet protégé, premier service utile. Un échec après le nom mais avant la preuve ne permet pas de conclure à une révocation ou à une attaque.

La resynchronisation ne peut pas signer sa propre autorité

Lorsque les caches divergent, envoyer un message de réparation paraît simple. Mais le message modifie un état de sécurité. Il doit donc être authentifié par une autorité encore commune.

La RFC recommande une resynchronisation par le protocole d’association sécurisée ou par une indication de couche inférieure. Si les parties partagent encore une clé apte à protéger cet échange, elles peuvent rapprocher leurs vues. Si cette racine commune a disparu, une réparation sécurisée fondée sur elle devient impossible.

Il ne suffit pas que l’une des parties affirme : « je possédais cette clé hier ». Une demande non protégée de recréer l’entrée ferait de la perte de preuve la source de sa propre autorisation. La voie correcte passe alors par une nouvelle authentification, éventuellement déclenchée à l’expiration d’un temporisateur.

Cette décision peut être plus lente. Elle est aussi vérifiable : une méthode EAP recommence, une décision AAA peut être réévaluée, de nouveaux secrets apparaissent et une nouvelle association se forme. La récupération ne prétend pas que l’ancien état existe encore.

Le périmètre peut diverger avant les octets

Même lorsque les deux caches contiennent une clé identique, ils peuvent lui attribuer des usages différents. La RFC 5247 recommande donc la synchronisation du périmètre : le pair doit pouvoir déterminer la portée du cache de chaque authentificateur, et l’authentificateur celle du pair, y compris les restrictions d’usage.

Une clé retenue pour un authentificateur ne vaut pas automatiquement pour un autre. Un contexte lié à un port, un SSID, une association ou un profil de trafic ne gagne pas un mandat plus large parce que sa date limite n’est pas atteinte. L’existence des octets et l’autorisation de les employer restent deux colonnes.

Cette séparation devient décisive lors d’un déplacement. Le terminal peut retrouver un identifiant connu tandis que le chemin AAA mène à un autre serveur, ou que l’authentificateur applique une politique de cache différente. La RFC explique aussi que des serveurs d’un même domaine peuvent vérifier les mêmes justificatifs sans partager tout leur état persistant. Un échec de reprise peut donc signaler une topologie d’état, pas une identité invalide.

Ne pas transformer une absence en accusation

Un tableau de bord qui n’offre que « succès » et « mauvais mot de passe » oblige l’exploitation à inventer une cause. Le résultat peut être coûteux : rotation inutile du secret de l’utilisateur, verrouillage de compte, incident de sécurité mal attribué ou augmentation de la capacité au mauvais endroit.

Il faut conserver l’échec le plus précoce observé. L’authentificateur n’a pas trouvé le nom ; la preuve mutuelle n’a pas abouti ; la dérivation fraîche a échoué ; l’activation n’a pas été confirmée ; la politique d’accès a refusé ; le trafic protégé n’a pas produit de service. Ces états orientent des réparations différentes.

L’inconnu est également un état honnête. Le texte normatif montre qu’un pair peut découvrir la perte distante uniquement en tentant l’usage. Cette tentative prouve une incompatibilité actuelle, pas la raison historique de l’effacement.

Tester la panne asymétrique

Les essais ordinaires effacent les deux côtés ou ne redémarrent rien. Ils manquent le cas le plus instructif. Quatre scénarios doivent être distincts : les deux caches conservent l’entrée ; seul le pair la conserve ; seul l’authentificateur la conserve ; aucun ne la conserve.

Pour chaque scénario, l’exploitant doit mesurer le temps de détection, le nombre de tentatives, le passage vers l’authentification complète, l’émission de nouvelles clés transitoires et le retour du trafic. Il faut aussi vérifier que l’ancienne clé n’est pas réactivée silencieusement après la réparation.

Un redémarrage collectif ajoute un risque économique. Le cache réduit la charge en régime normal ; sa disparition simultanée renvoie tout le monde vers la voie coûteuse. Une architecture dimensionnée sur le taux de réussite du raccourci peut s’effondrer au moment même où elle doit reconstruire son état.

Sources