Résumé

  • RFC 9965 réserve eap.arpa aux NAI par lesquels un pair EAP demande une voie de provisioning et un accès non authentifié, mais limité.
  • La demande, le choix de méthode, l’authentification du serveur, l’enfermement réseau, la délivrance d’un identifiant et l’admission ultérieure restent des faits distincts.

Un appareil peut annoncer @noob.eap.arpa ou un autre EPI et donner l’impression qu’il a déjà été reconnu. C’est précisément l’inférence que RFC 9965 refuse. Le document crée une grammaire commune pour demander du provisioning, pas une identité portable.

L’EPI est un NAI dont le domaine est un sous-domaine de eap.arpa.. Ce choix est volontairement séparé de toute organisation et ne doit pas être automatiquement routé par les proxys AAA existants ni découvert par le mécanisme dynamique habituel. Mais le RFC n’interdit pas à une organisation de traiter ce domaine. Ainsi, le protocole partage une demande lisible tandis que le routage, le serveur et la politique restent locaux.

Cette réserve évite de transformer un suffixe en preuve. Une trace EAP peut montrer qu’un pair a demandé une méthode de provisioning précise. Elle ne montre pas quel serveur l’a examiné, si le pair est authentifié, si un fournisseur d’identité a accepté une demande, ni si l’accès a été accordé. RFC 3748 rappelle qu’une authentification réussie peut encore être suivie d’un refus pour raison de politique ou de limite de session.

RFC 9965 impose de traiter le pair utilisant un EPI comme non fiable jusqu’à son authentification. Il doit alors être placé dans un réseau limité, par exemple un portail captif, qui ne permet pas l’accès sans restriction. Le point de contrôle n’est donc pas une page d’accueil symbolique : un réseau de provisioning sûr n’autorise que les flux attendus et bloque le reste. Bloquer quelques flux jugés mauvais ne produit pas le même périmètre, ni la même preuve d’exécution.

Le choix de méthode est tout aussi borné. Si le serveur EAP accepte la demande, il doit proposer la méthode associée à l’EPI ; le dialogue EAP ordinaire se poursuit ensuite. Cela n’est pas un certificat d’admission. C’est une cohérence entre une demande et une méthode. L’authentification du serveur doit être définie par chaque méthode de provisioning ; le RFC recommande des méthodes EAP fondées sur TLS pour protéger l’échange. Une obligation de conception ne prouve toutefois pas qu’une session donnée a validé un certificat ou un serveur déterminé.

La bonne comptabilité distingue donc : EPI reçu, décision locale de routage, méthode proposée, résultat d’authentification du serveur, règle de réseau limité appliquée, décision de délivrance et décision d’accès ultérieure. Cette séparation rend la récupération possible. Un pair peut cesser d’être éligible au provisioning sans que l’opérateur doive réécrire l’histoire comme s’il avait déjà été un utilisateur admis.