Résumé

  • Le tour unique d’ERP contient plusieurs transitions : admission et consommation d’un numéro de séquence par le serveur, Finish authentifié au pair, livraison AAA du rMSK, installation par l’authentificateur, puis établissement des clés de session.
  • La preuve doit suivre ces transitions séparément, car un compteur avancé ou un Finish valide ne démontre ni l’usage du rMSK ni l’ouverture effective de l’accès.

Le premier commit se trouve au serveur

RFC 5296 cherche à réduire le délai d’un déplacement entre authentificateurs. Le pair conserve une racine de réauthentification et envoie EAP-Initiate/Re-auth à un serveur ER, par l’intermédiaire de l’authentificateur. EAP-Finish/Re-auth revient dans le même aller-retour.

Le raccourci temporel ne fusionne pas les responsabilités. L’authentificateur relaie, le serveur juge la preuve du pair, le système AAA transporte une clé destinée à l’authentificateur, le pair dérive la même clé, puis un protocole de couche basse construit les clés de session transitoires.

La première mutation irréversible est souvent moins visible que la dernière : le serveur consomme un état anti-rejeu.

SEQ ne décrit pas à lui seul le verdict

Le message Initiate transporte un SEQ de 16 bits, un unique keyName-NAI, une suite cryptographique et une étiquette d’authentification. Pour une nouvelle rRK, SEQ repart de zéro. Le serveur vérifie la valeur attendue, ou son appartenance à une fenêtre non encore consommée, puis l’acceptabilité de la suite et l’intégrité avec rIK.

S’il accepte, il dérive rMSK à partir de rRK et de SEQ. Le Finish reprend le même SEQ ; le serveur augmente sa valeur attendue ou met à jour la fenêtre. Une perte ultérieure ne rembobine pas nécessairement ce commit.

Un journal utile conserve l’état attendu avant la décision, les bornes et la génération de fenêtre, le test d’usage antérieur, le verdict et l’état après. Une capture du paquet n’établit pas la transaction de stockage du serveur.

Identifier sépare le nouvel essai de la retransmission

Le pair porte les temporisateurs de retransmission. Une retransmission conserve le même Identifier EAP ; une nouvelle requête choisit un autre Identifier, surtout lorsqu’un échange reste ouvert. Le Finish doit correspondre à l’Initiate encore en attente.

Identifier et SEQ répondent donc à deux questions différentes. Le premier rattache la réponse à une tentative en cours. Le second protège contre le rejeu et participe à la dérivation du rMSK. Un identifiant de corrélation interne unique ne doit pas masquer cette dualité.

La recommandation d’effacer l’état ERP de l’authentificateur après 300 secondes ne prouve pas que le pair et le serveur ont effacé les leurs au même instant.

Le Finish protège le dialogue pair-serveur

Le pair vérifie qu’il attend le SEQ reçu sous le keyName-NAI indiqué, puis contrôle l’intégrité du Finish. Il peut alors calculer le rMSK. RFC 5296 dit qu’à ce point le protocole d’association de sécurité de couche basse est prêt à être déclenché.

Cette formulation interdit de confondre disponibilité et résultat. Le Finish établit une réponse provenant d’un détenteur de rIK dans le contexte ERP attendu. Il ne certifie pas la réception AAA par le bon authentificateur, l’installation locale, le choix de la même génération, le succès des TSK ni l’accès aux paquets.

Il faut des événements distincts pour l’émission et la vérification du Finish, la livraison AAA, l’accusé d’installation, le démarrage de la couche basse, son résultat et la décision d’accès.

Chaque rMSK appartient à un authentificateur

rMSK est dérivée avec un label fixe, SEQ et une longueur. Elle remplit auprès de l’authentificateur le rôle que joue MSK après un EAP complet. Une même rMSK ne doit pas être partagée entre plusieurs authentificateurs et sa durée ne dépasse pas celle de rRK.

Une nouvelle rRK gouverne les futures rMSK, mais les anciennes déjà distribuées peuvent rester valides jusqu’à expiration. La création de la nouvelle génération ne constitue donc pas un reçu de retrait. L’inventaire doit répondre par authentificateur.

Lors du bootstrap, la couche basse peut ignorer le nouveau rMSK si des TSK basées sur un MSK précédent sont déjà actives, ou lancer une nouvelle association. La réception est réelle dans les deux cas ; l’usage diffère.

Les exécutions parallèles transforment le prochain numéro en ensemble

Un pair peut lancer ERP à travers plusieurs authentificateurs vers le même serveur. L’ordre d’arrivée devient imprévisible. Le serveur peut accepter une fenêtre de valeurs inutilisées ; la maintenance de cette fenêtre relève de l’implémentation locale.

L’audit doit donc conserver les bornes, les valeurs déjà consommées, l’authentificateur de passage et la politique au moment du verdict. Sans cet instantané, une réorganisation valide ressemble à un rejeu, ou un rejeu bénéficie à tort de la tolérance prévue pour la concurrence.

Modifier la largeur de la fenêtre change l’autorité d’admission sans changer le format des messages. Cette configuration mérite son propre contrôle.

Un échec invérifiable ne désigne pas son auteur

Après une erreur, le serveur renvoie un Finish en échec. S’il possède rIK, il protège le message. Une suite refusée peut être accompagnée de suites acceptables ; le pair peut réessayer et doit recalculer la chaîne appropriée si la PRF change.

Si le contrôle de rejeu ou d’intégrité échoue, le message peut venir d’un attaquant, mais il peut aussi refléter une incompatibilité de suites. Le pair ne peut trancher. Il poursuit donc les retransmissions avant de déclarer l’échec.

Cette incertitude doit survivre dans l’alerte. La transformer immédiatement en attribution hostile donne au symbole plus de certitude que le protocole.

RFC 6696 exige un contexte encore vivant

RFC 6696 a remplacé RFC 5296 tout en restant compatible. Il clarifie notamment que l’authentificateur ou le serveur ER local doit vérifier qu’il possède actuellement la matière racine correspondante lors du bootstrap implicite. Retrouver un ancien contexte ou une identité ne suffit pas.

Cette vérification autorise une réponse ; elle ne prouve toujours pas l’installation terminale. La génération de racine doit rester liée au SEQ, au rMSK, à l’authentificateur et au résultat de couche basse.

Le reçu d’une réauthentification rapide

Conserver la génération et l’échéance rRK ; keyName-NAI et domaine ; Identifier ; SEQ ; fenêtre et état d’usage ; suite ; verdict d’intégrité ; admission serveur ; transition du compteur ; génération rMSK et liaison à un seul authentificateur ; Finish ; transaction AAA ; réception et installation ; vérification du pair ; clé choisie pour les TSK ; établissement et résultat d’accès ; retour à EAP complet ; retransmissions ; données et verdict de channel binding.

Les secrets restent hors du reçu. Celui-ci décrit l’ordre des commits, pas leur contenu cryptographique.

Sources