Résumé

  • RFC 9678 ajoute à EAP-AKA' une contribution ECDHE authentifiée et facultative, avec X25519 ou P-256, afin qu’une compromission ultérieure de la clé longue durée ne livre pas automatiquement les clés des sessions terminées.
  • La propriété suppose cependant la destruction de tous les éléments de session pertinents ; ni AT_PUB_ECDHE, ni AT_KDF_FS, ni un AT_MAC valide ne certifient cet effacement opérationnel.
  • L’assurance exige une chaîne distincte : politique, négociation, dérivation, usage en aval, clôture de session, inventaire des copies, destruction et essai indépendant de récupération.

Un journal exact, un instantané embarrassant

Le serveur d’authentification produit un dossier impeccable. Il montre l’offre de plusieurs valeurs AT_KDF_FS, la clé publique du serveur dans AT_PUB_ECDHE, le choix du pair et la validation du code d’authentification. L’équipe peut reconstituer la négociation sans ambiguïté. Sur cette base, le tableau de bord qualifie la session de « forward secret ».

Puis un instantané de mémoire, conservé pour analyser une panne, révèle encore la MSK. Le protocole n’a pas menti. Le tableau de bord a simplement attribué à la trace une conclusion qu’elle ne contenait pas.

La trace prouve que les deux extrémités ont participé à l’échange défini par RFC 9678 et que les nouveaux attributs ont été protégés par le mécanisme d’authentification d’EAP-AKA'. L’instantané répond à une autre question : les éléments dérivés sont-ils devenus irrécupérables après la fin de la session ? Une même organisation peut obtenir une réponse positive à la première question et négative à la seconde.

C’est pourquoi la confidentialité persistante ne se réduit pas à un algorithme. Elle associe un calcul cryptographique à une discipline de cycle de vie.

La modification normative

Publié en mars 2025 comme Proposed Standard, RFC 9678 met à jour RFC 9048 et son prédécesseur RFC 5448. EAP-AKA' s’appuie sur la relation de confiance liée à une clé symétrique longue durée, présente du côté de l’abonné et du réseau d’origine. Cette architecture pose un risque rétrospectif : un adversaire peut enregistrer des communications, obtenir plus tard la clé longue durée et tenter de reconstruire des secrets de sessions anciennes.

L’extension ajoute une contribution indépendante. Le serveur envoie une clé publique ECDHE et une liste ordonnée d’options de dérivation. Le pair choisit une option qu’il prend en charge et renvoie sa propre valeur publique. Le registre IANA attribue les types 152 et 153 aux nouveaux attributs. Le document définit notamment X25519 et P-256.

Les attributs participent au calcul de AT_MAC. Cette liaison empêche un observateur non authentifié de remplacer discrètement la clé publique ou le choix de dérivation. Le secret Diffie-Hellman contribue à MK_ECDHE, puis à K_re, à la MSK et à l’EMSK.

Le résultat est important : la seule clé longue durée ne doit plus suffire à retrouver les clés d’une session passée correctement protégée. Le résultat n’est pourtant pas absolu. Il dépend du moment de la compromission et de la disparition effective des secrets de session.

Une authentification réussie peut avoir emprunté deux routes

L’extension reste facultative. Un pair qui ne la prend pas en charge peut ignorer les attributs et poursuivre avec EAP-AKA' ordinaire, si sa politique l’autorise. Si la politique exige la confidentialité persistante, l’absence d’un choix commun conduit à un échec plutôt qu’à une protection fictive.

Ainsi, le mot « succès » recouvre deux routes. Une authentification peut réussir après négociation ECDHE. Une autre peut réussir par compatibilité héritée sans cette propriété. Additionner les deux produit une mesure de disponibilité, pas une mesure de confidentialité persistante.

Les politiques du pair et du serveur forment donc une surface de décision. Quels terminaux anciens peuvent se connecter ? Pendant combien de temps l’exception reste-t-elle valable ? Quel domaine administratif accepte le repli ? Une évolution stricte peut provoquer des refus visibles ; une évolution permissive peut accumuler des sessions vulnérables à une future fuite de clé longue durée. Le RFC expose le mécanisme, sans prétendre résoudre ce choix pour tous les opérateurs.

La condition d’effacement est explicite

L’analyse de sécurité de RFC 9678 conditionne sa protection des sessions terminées à la suppression des éléments de session pertinents. L’extrémité ne doit pas seulement abandonner sa clé privée éphémère. Elle doit aussi éliminer les clés dérivées qui permettraient de retrouver ou d’utiliser l’état protégé.

La liste des lieux possibles dépasse le processus EAP : mémoire du pair et du serveur, cache d’un service d’authentification, accélérateur matériel, contexte de réauthentification, point d’accès, passerelle, export de diagnostic, fichier d’échange, image d’hibernation, vidage mémoire, sauvegarde ou collecte forensique.

Une fonction de destruction appelée par une bibliothèque ne certifie pas les copies créées avant cet appel. Un descripteur détruit ne certifie pas qu’un journal de débogage n’a pas reçu la valeur. Le chiffrement d’une sauvegarde protège son accès ; il ne signifie pas que le secret a été détruit. Il faut donc inventer l’ensemble avant de pouvoir affirmer que l’ensemble a disparu.

La fin de session est, elle aussi, plurielle. EAP peut avoir terminé alors que la couche d’accès conserve une association. Un tunnel ou un contexte de mobilité peut prolonger l’usage d’une clé. Un serveur peut expirer son entrée avant une passerelle. La preuve doit nommer le composant, l’événement de clôture et la limite de rétention applicables à chaque classe de clé.

La réauthentification n’est pas un nouveau Diffie-Hellman

Lorsque l’authentification complète initiale utilise l’extension, K_re bénéficie de la contribution ECDHE. Les réauthentifications ultérieures conservent ainsi une résistance à la compromission future de la clé longue durée.

Mais RFC 9678 ne lance pas un nouvel échange Diffie-Hellman à chaque réauthentification. L’événement qui paraît récent dans l’exploitation hérite d’un accord antérieur. Son niveau d’assurance dépend de la conservation de K_re, du nombre de réutilisations et de la politique qui impose éventuellement une nouvelle authentification complète.

Une interface qui inscrit « nouvel ECDHE » à chaque réauthentification invente un calcul. Une interface fidèle indique l’origine du contexte, son âge et le prochain seuil de renouvellement complet.

La couche consommatrice décide de l’effet réel

EAP remet une MSK et une EMSK à d’autres protocoles. La portée pratique de RFC 9678 dépend de ce qui se passe ensuite. Un chemin IKEv2 qui réalise déjà son propre échange éphémère peut offrir une confidentialité persistante indépendante pour le tunnel. Une protection de liaison directement fondée sur les sorties EAP peut dépendre beaucoup plus fortement de la nouvelle extension.

Il faut donc relier l’instance de MSK au consommateur exact. Quelle association l’a utilisée ? Un autre échange éphémère est-il intervenu ? Quand ce consommateur a-t-il cessé l’usage ? A-t-il exporté ou mis en cache la clé ? La négociation EAP, isolée de ces réponses, ne prouve pas le sort des données évoquées dans un rapport de direction.

Un adversaire situé dans le temps

L’extension vise surtout l’adversaire qui obtient la clé longue durée plus tard. Elle ne prétend pas neutraliser un attaquant actif qui possède déjà cette clé pendant l’authentification en cours et se trouve sur le chemin. Celui-ci peut attaquer la session vivante et observer le trafic qui en résulte.

Une affirmation rigoureuse précise donc le scénario : session identifiée, extension effectivement sélectionnée, transcript authentifié, consommateur connu, session terminée, éléments pertinents détruits, puis compromission ultérieure de la clé longue durée. Supprimer cette chronologie transforme une garantie ciblée en slogan universel.

La chaîne de preuves

La première pièce est la politique des deux extrémités : extension obligatoire, préférée ou facultative, repli permis ou interdit. Viennent ensuite les capacités logicielles, l’offre ordonnée, le choix, les clés publiques et la validation du transcript. Ces éléments démontrent l’accord sans conserver les secrets privés.

La dérivation doit être reliée, au moyen d’identifiants non secrets, aux contextes MSK, EMSK et K_re, puis à leurs consommateurs. Chaque repli doit être étiqueté. Chaque composant doit produire son propre événement de fin.

L’organisation inventorie ensuite les surfaces de copie et enregistre leur destruction ou leur invalidation cryptographique. Les exceptions de conservation restent visibles. Enfin, un essai autorisé tente une récupération à partir du transcript archivé et de la clé longue durée révélée plus tard.

L’échec de cet essai, dans un périmètre déclaré, est une preuve plus proche de la promesse réelle qu’un simple drapeau de configuration. Il ne démontre pas l’impossibilité mathématique de toute fuite inconnue. Il montre que la chaîne connue a résisté au test prévu.

De la spécification au code exécuté

RFC 9678 constitue une spécification initiale minimale : des attributs communs, des algorithmes, des règles de négociation et une dérivation. Les décisions futures restent locales : prise en charge, repli, durée des contextes, gestion mémoire, effacement et audit.

La grille de Heng Lu aide à ne pas confondre les couches. Le numéro d’attribut appartient à la coordination. Le transcript authentifié appartient au protocole. Les octets en mémoire appartiennent au code exécuté. La session d’accès appartient à l’exploitation. Le test de récupération appartient à la preuve. La mention « confidentialité persistante » appartient au récit de direction.

La qualité de la gouvernance se mesure à sa capacité à préserver ces distinctions. Le RFC fournit la route cryptographique. L’opérateur doit encore montrer que les clés ont quitté la route sans laisser de copie exploitable.

Sources