Résumé

  • Le FRID est un NAI pseudonyme créé par le serveur pour retrouver un contexte EAP-IKEv2 existant. Sa reconnaissance n’établit pas que le pair qui le présente maîtrise les clés de ce contexte.
  • Le raccourci ne réussit qu’après vérification des messages protégés avec l’ancien contexte, nouveaux SPI et nonces frais, puis dérivation d’un MSK et d’un EMSK frais. L’autorisation réseau et le service restent des décisions ultérieures.

Un incident de reprise commence par une contradiction. Le serveur affirme avoir envoyé le prochain Fast-Reconnect-ID lors de la dernière session. Le terminal revient pourtant avec l’identifiant précédent. Faut-il supprimer l’ancien comme obsolète, ou accepter que « transmis » ne signifie pas « conservé » ?

Le RFC 5106 choisit la seconde lecture. Son mode fast reconnect est obligatoire à implémenter, facultatif à utiliser et dépend de la politique locale. Il suppose qu’un serveur EAP et un pair EAP ont déjà réalisé une authentification mutuelle complète et conservent tous deux le contexte correspondant.

Dans l’échange complet, le serveur joue le rôle d’initiateur IKEv2. Les messages protégés contiennent les identités et les valeurs AUTH nécessaires à l’authentification mutuelle. EAP-Success ne vient qu’après ces contrôles. Le serveur peut alors insérer un payload Next Fast-ID, ou NFID, destiné à l’exécution suivante.

NFID porte le FRID. Cet identifiant respecte le format NAI : nom d’utilisateur pseudonymisé et realm routable. Le serveur fabrique le pseudonyme et garde la correspondance avec l’identité permanente et le contexte. Le realm doit rester lisible pour l’infrastructure AAA ; la confidentialité est donc partielle et intentionnelle.

Le caractère aléatoire recommandé du nom d’utilisateur sert de référence au contexte. Il n’en fait pas une preuve de possession. Une valeur trouvée dans une table répond à « quel état tenter ? », non à « qui contrôle les clés ? ». C’est l’échange protégé qui répond à la seconde question.

Le RFC reconnaît aussi la topologie. Rien ne garantit que la tentative suivante atteigne le serveur ayant créé le pseudonyme. Les serveurs du même opérateur peuvent partager une résolution centralisée. Sinon, celui qui ne comprend pas le FRID peut demander l’identité permanente. Un échec de résolution peut révéler une réplication absente, une éviction ou un routage différent ; il ne prouve pas automatiquement une attaque.

Le pair ne doit présenter un FRID que si l’échange réussi précédent l’a fourni. La réponse EAP-Identity reste obligatoire. Après la résolution, la politique du serveur choisit le fast reconnect ou le retour à l’échange complet. Même un pair légitime ayant proposé le raccourci doit savoir recevoir le message 3 complet.

La machine d’état comporte donc déjà quatre actes : émission de NFID, stockage éventuel chez le pair, présentation de FRID, résolution côté serveur. Aucun n’est EAP-Success. La qualité d’une implémentation se voit à sa capacité à conserver ces distinctions dans les journaux.

Le cœur cryptographique arrive avec les messages 3 et 4 du fast reconnect. Ils ressemblent à un renouvellement d’IKE SA et sont chiffrés et protégés en intégrité au moyen des clés du contexte précédent. Le serveur choisit un nouveau SPI non nul pour la proposition et un nonce Ni frais. Une valeur Diffie-Hellman nouvelle peut être ajoutée. Le pair vérifie le message, choisit son nouveau SPI, produit Nr et protège sa réponse.

Le serveur déchiffre et vérifie le message 4. Seule la réception d’un message 4 correct rend l’exécution réussie et autorise EAP-Success. Le cache peut donc avoir trouvé exactement la bonne ligne alors que l’authentification échoue : anciennes clés divergentes, intégrité incorrecte, nonce réutilisé ou réponse absente.

Le succès produit un nouvel état et non une simple prolongation nominale. SKEYSEED combine l’ancien SK_d, Ni, Nr et éventuellement un nouveau secret Diffie-Hellman. Les clés propres à EAP-IKEv2 sont régénérées. KEYMAT fournit ensuite 64 octets de MSK et 64 octets d’EMSK. Le RFC interdit leur génération avant l’achèvement réussi.

Session-ID utilise le type EAP-IKEv2 et les nouveaux Ni et Nr. Peer-ID et Server-ID restent issus de l’échange complet qui a créé le contexte. Le pseudonyme présenté, les identités authentifiées et la session actuelle ont donc trois sémantiques distinctes. Les ranger dans une seule colonne identity rend l’enquête ambiguë.

La rotation de FRID est une petite transaction distribuée. Le serveur peut joindre un nouveau NFID au message 3. Le pair peut recevoir le paquet puis tomber en panne avant d’enregistrer durablement la valeur. Pour survivre à ce cas, le serveur devrait garder le FRID le plus récemment utilisé et celui le plus récemment émis.

La règle décisive est plus forte : si l’authentification ne se termine pas avec succès, le serveur ne doit pas écraser le FRID de la dernière authentification réussie. La nouveauté non confirmée ne peut pas détruire l’état partagé connu. Un système qui fait du « dernier émis » la seule vérité transforme une optimisation en mécanisme de verrouillage.

La protection contre le rejeu dépend elle aussi des générations de clés. Un ancien message 3 capturé doit échouer après une reconnexion réussie, car les clés de vérification ont changé. Le journal doit donc corréler tentative, génération de contexte et transition réussie. Compter deux apparitions du même FRID ne suffit pas à distinguer retransmission, reprise légitime et rejeu.

EAP-Success reste une frontière interne à la méthode. Le RFC 5247 place l’export de clés dans un cadre plus large. La décision AAA, l’installation par l’authenticator, l’ouverture du port contrôlé, le premier trafic protégé et le service applicatif ont leurs propres acteurs et preuves.

Le RFC 5106 ne prend pas en charge le channel binding. Même une exécution cryptographiquement correcte ne certifie donc pas toutes les propriétés du réseau d’accès sous-jacent. Un tableau de bord qui traduit EAP-Success en « accès correct au bon réseau » ajoute une conclusion que la méthode n’a pas fournie.

Les algorithmes historiques doivent enfin être datés. Le profil d’interopérabilité de 2008 mentionne MODP 1024, 3DES et des constructions SHA-1. Leur présence décrit le document expérimental de l’époque ; elle n’est pas une recommandation automatique pour un déploiement actuel. La conformité protocolaire et l’acceptabilité cryptographique appartiennent à deux décisions.

Une piste de preuve utile enregistre le digest du FRID, le realm, le serveur émetteur, la génération de contexte et l’échange réussi qui confirme la rotation. Pour chaque tentative : résultat de résolution, choix fast/full, époque de clés, SPI, digests de Ni/Nr, groupe DH éventuel, vérifications des messages 3 et 4, résultat EAP, identifiant de session et handles de clés exportées. Les clés brutes n’ont pas à quitter leur protection.

Les systèmes suivants ajoutent politique AAA, installation et trafic. Les alertes doivent nommer le bord manquant : FRID inconnu, contexte divergent, intégrité du message 3 ou 4 en échec, réutilisation de nonce, succès sans export, autorisation sans installation, installation sans trafic.

La reconnexion rapide ne supprime donc pas la preuve. Elle réutilise une confiance cryptographique déjà établie afin de produire, avec des entrées fraîches, un nouveau contexte. Le FRID accélère la sélection. Seul l’échange réussi autorise la transition.

Sources