Résumé

  • Lorsqu’un serveur accepte de reprendre une session TEAP, RFC 9930 prévoit que la phase 2 est entièrement contournée ; le ticket doit donc rester relié à l’authentification interne et aux justificatifs qui fondent l’autorisation actuelle.
  • Si les nouveaux justificatifs ne peuvent pas être associés au ticket, le serveur doit invalider celui-ci et imposer une authentification complète lors de la connexion suivante.

La reprise répond à un vrai problème d’exploitation. Dans un environnement où utilisateurs et machines se réauthentifient plusieurs fois par jour, refaire chaque méthode interne multiplie les consultations du référentiel d’identités. RFC 9930 impose donc aux implémentations TEAP de prendre en charge la reprise et souligne son apport à la stabilité et à la montée en charge. Cette obligation porte sur la capacité, pas sur l’acceptation automatique de tout ticket présenté.

Une session TEAP complète sépare deux moments. La phase 1 utilise TLS pour établir un tunnel protégé et authentifié. La phase 2 transporte les méthodes internes et les TLV : authentification d’une machine, d’un utilisateur ou des deux, fourniture ou remplacement d’un justificatif, liaison cryptographique et résultats protégés. RFC 6678 décrit les exigences d’une méthode EAP à tunnel normalisée ; RFC 3748 en fixe les rôles et le modèle de résultat. Un tunnel établi ne vaut pas achèvement de ce qui devait s’y dérouler.

La reprise exploite précisément cette différence. Si le serveur l’accepte, RFC 9930 indique que toute la phase 2 est évitée. S’il la refuse, les parties terminent une poignée de main TLS complète puis doivent exécuter la phase 2. L’état peut rester côté serveur ou être porté par un mécanisme de ticket côté client, comme dans RFC 5077. Avec TLS 1.3, RFC 8446 fait de NewSessionTicket le support d’un état lié à une PSK pour une connexion future. Ce support n’atteste pas que l’autorisation future n’aura rien à réexaminer.

Il existe même un cas où le ticket précède l’authentification interne. RFC 9427 rappelle que TLS 1.3 permet l’envoi de NewSessionTicket après le message Finished du client, alors que la méthode interne n’a peut-être pas encore été exécutée. Un client pourrait obtenir ce ticket, interrompre la session puis tenter une reprise sans avoir jamais passé l’étape interne. Le serveur ne doit donc autoriser aucune reprise si cette authentification n’a pas réussi. Il devrait différer l’émission du ticket ; sinon, il doit invalider ou écarter ceux des sessions en échec. Si l’état du ticket ne permet pas de trancher, l’échec de preuve oblige à refaire les méthodes internes avant tout accès.

La réussite interne n’est pas non plus une autorisation monolithique. Après chaque méthode réussie, RFC 9930 prévoit Intermediate-Result et Crypto-Binding. Le Compound MAC relie le tunnel aux participants et à la séquence d’authentification ; il peut révéler une substitution ou une rupture de liaison. Il ne sélectionne ni VLAN, ni ACL, ni rôle, ni état de compte. Le pair peut d’ailleurs demander une action supplémentaire malgré un Result TLV réussi si sa propre politique n’est pas satisfaite, et le serveur reste libre d’y répondre selon sa politique.

Le problème temporel subsiste après une première session parfaitement régulière. La phase 2 peut créer ou modifier des justificatifs. L’autorisation ultérieure doit donc s’appuyer sur les justificatifs authentifiés, et non sur une identité anonyme ou différente présentée en phase 1. La même exigence vaut lors de la reprise : les nouveaux justificatifs doivent être associés au ticket. Si cette association est impossible, le serveur doit invalider les tickets de la session. La connexion suivante repasse alors par l’authentification complète afin qu’un nouveau ticket puisse recevoir une base d’autorisation explicable.

RFC 9190 élargit ce contrôle aux autres données qui peuvent changer entre la poignée de main initiale et la reprise : informations sur le pair, l’authentificateur ou les couches environnantes. Si une différence peut modifier une décision d’autorisation, de comptabilité ou de politique, cette décision doit être réévaluée. Quand aucune conclusion sûre n’est possible, le serveur devrait refuser la reprise et poursuivre par une poignée de main complète. Le plafond de sept jours d’un ticket TLS 1.3 n’est donc pas un droit d’accès de sept jours.

Le dossier d’exploitation doit relier sans les confondre : empreinte du ticket ou du Session ID, émetteur, émission et expiration, session complète d’origine, réussite interne, versions des justificatifs et de la politique, contexte de l’authentificateur, changements intervenus, réévaluation et motif d’acceptation, de rejet ou d’invalidation. Viennent ensuite, séparément, la décision d’autorisation, la preuve d’application par le NAS et l’observation du trafic ou du service. RFC 5247 encadre les identités et les clés EAP ; il ne fournit pas ces preuves aval.

La doctrine de spécification minimale de Heng Lu offre ici une discipline simple. Le ticket partagé transporte un état borné utile à l’interopérabilité. La décision future reste locale et imputable. Le code en production doit montrer quelles données il a réellement consultées, et les plans de réalité restent distincts : ticket, justificatif authentifié, politique actuelle, autorisation, application, résultat. Une reprise sûre est une économie de travail que l’on peut expliquer et révoquer.

Sources