Résumé

  • Le RFC 5421 décrit EAP-FAST-GTC avec le type 6, déjà attribué à EAP-GTC, pour un échange interne différent transporté dans le tunnel.
  • Les interdictions d’usage dedans/dehors et l’avis de compatibilité de l’IESG font du contexte EAP-FAST une partie de l’identité de la méthode ; c’est une implication pour l’implémentation, pas la preuve d’une panne mesurée.

Le même octet ne suffit pas

Dans EAP, le champ Type tient sur un octet, mais il joue un rôle décisif. Le RFC 3748 explique qu’il identifie la méthode et que les couches EAP aiguillent les paquets vers celle-ci selon le type, par analogie avec un numéro de port de transport. À première vue, un paquet de type 6 appelle donc Generic Token Card.

Le RFC 5421 complique ce réflexe. Ce mémo informatif de 2009 décrit EAP-FAST-GTC, méthode interne d’échange élémentaire de mot de passe. Ses usages annoncés couvrent notamment des bases de mots de passe héritées, les changements de mot de passe et les codes à usage unique. Pour des raisons historiques, elle reprend le code déjà attribué à EAP-GTC. Le registre de l’IANA affiche toujours « Generic Token Card » pour le type 6 : le RFC 5421 n’a pas créé une seconde attribution mondiale.

La différence réside dans le cadre et dans la charge utile. EAP-FAST établit un tunnel TLS ; pendant sa phase interne, les paquets EAP sont encapsulés dans des TLV EAP Payload. Le RFC 5421 précise que le format EAP-FAST-GTC est propre au tunnel et n’est pas nécessairement compatible avec EAP-GTC utilisé à l’extérieur. Il impose alors deux règles réciproques : EAP-FAST-GTC NE DOIT PAS être utilisé hors d’un tunnel EAP-FAST, et EAP-GTC NE DOIT PAS être utilisé à l’intérieur.

Ces règles déterminent aussi ce que signifie le type 6 dans chaque contexte. Si le répartiteur ne conserve que l’octet Type et oublie si le paquet vient de l’échange extérieur ou de la phase interne EAP-FAST, il perd une information utilisée par le protocole pour distinguer les méthodes. C’est une conséquence pour l’implémentation, pas l’affirmation que des systèmes déployés ont commis cette erreur.

L’avertissement figure dans le RFC

L’avis de l’IESG joint au RFC 5421 qualifie la réutilisation de types EAP attribués d’incompatible avec la négociation de méthode du RFC 3748. Il explique qu’EAP-FAST-GTC est implicite dans le tunnel parce qu’EAP-GTC ne prévoit pas de négociation de version propre à la méthode. Cela peut poser problème lorsque l’implémentation doit aussi prendre en charge l’EAP-GTC d’un autre fournisseur ; prendre en charge le même code dans et hors du tunnel complique également l’implémentation.

L’avis indique qu’un code Type unique aurait évité ces difficultés et demande de ne pas réutiliser à l’avenir un type attribué avec un autre sens dans une méthode tunnelisée.

Cette formulation doit rester à sa juste portée : elle ne démontre ni l’échec de toutes les négociations, ni la révocation du type 6, ni un défaut dans un produit actuel. Elle documente le coût de compatibilité d’un sens dépendant du contexte. Le registre donne le nom global ; les règles du tunnel encadrent l’usage interne ; l’avis de l’IESG expose la tension entre les deux.

La primauté du code en fonctionnement fournit ici un angle éditorial utile : une entrée de registre n’est pas tout le système. Le résultat dépend aussi du code qui reçoit le paquet, identifie sa couche et sélectionne la méthode. La Note 65 de Heng Lu éclaire cet angle ; elle ne constitue pas une preuve sur EAP ni sur les déploiements des fournisseurs.

La protection des identifiants est une autre frontière

Le RFC 5421 indique aussi que les mots de passe passent comme chaînes en clair à l’intérieur du tunnel TLS chiffré. Le pair doit authentifier le serveur avant de révéler ses identifiants. EAP-FAST-GTC NE DOIT PAS être utilisé en mode Server-Unauthenticated Provisioning, qui n’authentifie pas le serveur. Cette contrainte de sécurité est essentielle mais distincte de la question du code Type : protéger les identifiants ne résout pas à elle seule la sélection de méthode, et une sélection correcte ne garantit pas que le serveur ait été authentifié.

Pour l’exploitant, le point d’examen est la jonction : où l’implémentation décide-t-elle si le type 6 désigne EAP-GTC ou EAP-FAST-GTC ? La réponse devrait tenir compte à la fois du type et de la phase du tunnel, et appliquer les interdictions réciproques. Les tests peuvent vérifier GTC à l’extérieur, FAST-GTC à l’intérieur, puis rejeter chaque méthode dans le contexte opposé. Il s’agit de pratiques de vérification proposées ici, et non de nouvelles exigences du RFC.

Le RFC 5421 est informatif. Les sources publiques examinées ne permettent pas de mesurer l’adoption actuelle, les comportements des fournisseurs ou des incidents. La leçon est plus précise : lorsqu’un code est réutilisé sous un tunnel, le cadre qui le transporte devient un contexte opérationnel que le répartiteur ne peut pas oublier sans risque.

Sources