Résumé

  • RFC 5281 organise EAP-TTLSv0 en deux phases. La première ouvre un canal TLS et authentifie le serveur TTLS ; sauf certificat client, l’identité réelle de l’abonné n’est traitée qu’ensuite, dans le tunnel.
  • Le reçu complet doit distinguer identité externe de routage, validation du serveur, méthode et identité internes, décision AAA, autorisation, remise des clés, exécution au point d’accès et trafic observé.

La sécurité du canal était le début de l’authentification

La première phase d’EAP-TTLS exécute TLS. Le client vérifie le certificat du serveur, les deux côtés choisissent les paramètres cryptographiques, puis ChangeCipherSpec et Finished ferment la négociation. Le canal peut alors protéger des données supplémentaires.

Cette réussite a un sujet précis : le serveur TTLS et le canal qui y mène. L’authentification du client par certificat est facultative. Dans le cas ordinaire où TLS est unilatéral, l’utilisateur ne s’est pas encore authentifié. La phase 2 transporte les AVP contenant l’identité et la preuve interne.

Une console qui passe directement de TLS Finished à « utilisateur authentifié » efface le choix architectural central de RFC 5281. Elle transforme un moyen protégé de poser la question en réponse positive à cette question.

Le contexte cryptographique a depuis évolué. RFC 8996 interdit TLS 1.0 et 1.1, tandis que RFC 9427 adapte EAP-TTLS à TLS 1.3. Ces mises à jour ne donnent pas au handshake une autorité nouvelle sur l’identité interne, l’autorisation ou le service.

L’identité visible sert d’abord à acheminer

Avant que le tunnel existe, le point d’accès demande généralement une EAP-Response/Identity. Pour éviter d’exposer le nom réel, RFC 5281 recommande une valeur vide ou un pseudonyme, tout en autorisant le domaine nécessaire au routage, par exemple une identité anonyme accompagnée d’un realm.

Ce realm aide à envoyer la conversation vers un fournisseur de confiance. Il ne prouve pas quel compte, appareil ou individu sera ensuite authentifié. L’identité externe est un indice d’acheminement ; l’identité interne est une proposition soumise à l’autorité AAA.

Les journaux doivent conserver les deux sans les fusionner. Remplacer la première valeur par la seconde détruit la trace de routage. Conserver seulement la première attribue une décision d’accès à un pseudonyme. Il faut également savoir quel relais et quel serveur ont observé chaque valeur.

Le chiffrement s’arrête au terminateur TTLS

Les AVP de phase 2 sont chiffrés entre le client et le serveur TTLS. Celui-ci termine TLS, retrouve les AVP en clair et transmet les éléments d’authentification au serveur AAA du domaine d’origine. Les deux fonctions peuvent résider dans la même machine, mais le protocole ne l’exige pas.

Le tunnel extérieur n’est donc pas une protection de bout en bout jusqu’à AAA/H. Le transport backend possède sa propre association de sécurité, ses propres intermédiaires et ses propres règles. Le terminateur est un acteur qui voit et transforme les données, pas une vitre invisible.

RFC 5281 ajoute une précaution de sémantique : partager un code AVP entre EAP-TTLS, RADIUS et Diameter ne garantit pas que son sens soit identique. Le serveur ne doit pas copier un attribut vers un autre contexte s’il ne comprend pas la définition des deux côtés.

Une décision AAA peut être une séquence

AAA/H peut défier, accepter ou rejeter. Les défis reviennent par le serveur TTLS dans le canal. Lorsque l’autorité termine, le résultat remonte dans l’EAP externe et conduit normalement à EAP-Success ou EAP-Failure.

Plusieurs authentifications internes peuvent se succéder. La politique peut exiger qu’elles réussissent toutes, ou qu’une seule suffise. « La méthode interne a réussi » ne décrit donc pas la décision globale sans la liste des méthodes et la règle d’agrégation.

La phase 2 peut aussi être absente légitimement : un certificat client accepté pendant la phase 1 peut suffire, ou une reprise valide peut hériter d’une authentification antérieure réussie. L’observateur doit connaître la branche. L’absence de trafic interne n’est ni succès ni échec en soi.

En revanche, mettre en cache une session qui a réussi TLS mais échoué l’authentification interne est une faute critique. RFC 5281 qualifie la conséquence de catastrophique : la reprise pourrait transformer un échec d’utilisateur en accès sans nouvelle vérification.

Des octets de clé ne sont pas une permission

Le secret TLS permet de dériver MSK et EMSK. À la fin d’une authentification réussie, le serveur TTLS peut remettre le matériel de clé et les informations d’autorisation au point d’accès par le protocole AAA.

La dérivation et la permission n’appartiennent pas au même plan. Des octets peuvent être calculables avant la décision, envoyés à la mauvaise session, accompagnés d’une politique périmée ou installés sur un lien incapable de fournir le service attendu.

Le contrôle pertinent relie la clé au transcript, à l’identité authentifiée, à la décision AAA, à la session du point d’accès et à l’état effectivement installé. Une empreinte de clé sans ces liaisons ne clôt pas le chemin d’accès.

Le succès emprunte deux directions

Le client reçoit normalement EAP-Success. Le point d’accès reçoit, via AAA, des clés et des paramètres tels que filtres, durée, réseau logique ou limites. Ces sorties proviennent de la même décision, mais elles ne sont pas le même reçu.

EAP-Success ne montre pas que le point d’accès a appliqué le bon profil. Access-Accept ne montre pas que le client a observé la réussite. L’activation du chiffrement de liaison ne montre ni routage fonctionnel ni application disponible.

Pour une affirmation de service, il faut un témoin au point d’exécution et un autre à la frontière applicative. L’autorité d’authentification peut dire ce qu’elle a décidé ; elle ne peut pas voir par procuration tout ce qui s’est produit ensuite.

Le défaut de liaison de la version de base

RFC 5281 reconnaît qu’EAP-TTLSv0 ne lie pas cryptographiquement l’authentification extérieure à l’authentification intérieure. Si la même preuve de secret est utilisable dans un protocole tunnelé et non tunnelé, un adversaire peut la relayer. Le document déconseille cette réutilisation et renvoie à des extensions de liaison.

Deux contrôles réussis ne deviennent donc pas automatiquement une preuve composée. Cette limite ne condamne pas tout déploiement, mais elle interdit de prêter à la version de base une propriété venue d’une extension ou d’une méthode plus récente.

Le reçu d’accès à conserver

Un dossier sérieux réunit au minimum :

  • identités du client, du point d’accès, du serveur TTLS et d’AAA/H ;
  • identité externe, realm et chemin de routage ;
  • chaîne du certificat serveur, nom attendu et politique de validation ;
  • version TLS, suite, transcript et fin de phase 1 ;
  • branche certificat client, authentification interne ou reprise ;
  • identité interne, méthodes, défis et résultats ;
  • transaction entre terminateur TTLS et AAA/H ;
  • décision AAA, version de politique et autorisation retournée ;
  • résultat EAP vu par le client ;
  • remise des clés et association à la session d’accès ;
  • filtres et paramètres réellement installés ;
  • protection de liaison et trafic bidirectionnel ;
  • résultat applicatif exigé par l’affirmation publique.

Le dossier doit pouvoir s’arrêter honnêtement à chaque frontière. Un tunnel sûr peut contenir un abonné rejeté. Un abonné accepté peut rencontrer une exécution défaillante. Un lien exécuté peut rester inutilisable. La précision empêche le premier voyant vert de gouverner tous les suivants.

Sources