Résumé

  • Les identifiants de provisionnement EAP de RFC 9965 sont des demandes publiques, formulées dans le realm eap.arpa. Ils indiquent une méthode souhaitée, mais n’attestent ni l’identité ni le droit d’admission de l’appareil.
  • Le pair accepté reste non fiable. Le réseau doit autoriser seulement les flux attendus, isoler les pairs et borner la durée, les octets, les services, les tentatives ainsi que le nombre de sessions simultanées.
  • Un reçu de fermeture de la voie de provisionnement devrait relier la demande à la règle réellement appliquée, puis prouver son expiration ou son retrait. Cette proposition éditoriale de Daniel Kade ne fait pas partie de RFC 9965.

Une exception avant l’identité

L’authentification réseau suppose généralement que le terminal dispose déjà d’un secret, d’un certificat ou d’une autre preuve. Le premier enrôlement inverse cette logique : l’appareil doit atteindre un service pour recevoir ce qui lui permettra, plus tard, de s’authentifier. RFC 9965 traite ce paradoxe par des identifiants de provisionnement EAP, les EPI.

L’EPI adopte le format NAI de RFC 7542. Son realm eap.arpa et son nom d’utilisateur signalent le mécanisme demandé. Le registre de l’IANA associe notamment @noob.eap.arpa à EAP-NOOB et portal@tls.eap.arpa à EAP-TLS. L’uniformité de ces chaînes permet au serveur de reconnaître une intention avant qu’un identifiant propre à l’appareil existe.

Cette qualité est aussi leur limite. Une chaîne prédéfinie n’est pas rare, ne prouve aucune possession exclusive et ne désigne pas un acheteur, un locataire ou un équipement inventorié. Elle peut être présentée par n’importe quel pair capable de démarrer l’échange. Le registre gouverne le sens technique de la demande ; il ne gouverne pas la légitimité locale du demandeur.

RFC 9965 l’énonce par le comportement attendu du serveur. Une EPI mal formée conduit à un échec EAP. Une EPI inconnue, une méthode non prise en charge ou une méthode incompatible reçoit un Nak de type zéro. Le serveur ne doit pas négocier librement une autre méthode à partir d’un identifiant de provisionnement. Si la demande est acceptée, le pair doit néanmoins être considéré comme non fiable et placé sur un réseau limité.

Le mot « accepté » décrit donc seulement l’entrée dans une procédure. Il ne vaut pas reconnaissance du terminal. Le réseau conserve la liberté de refuser, notamment pour des raisons de capacité ou de politique qu’il n’est pas obligé de révéler. La future admission complète dépendra d’une nouvelle preuve et d’une nouvelle décision.

eap.arpa n’est pas une délégation de confiance

La graphie ressemble à un nom de domaine, ce qui peut induire une mauvaise lecture. RFC 9965 distingue le realm NAI eap.arpa du domaine eap.arpa. et réserve ce dernier sans en faire un service DNS ordinaire. Les requêtes DNS devraient recevoir NXDOMAIN ; le nom ne doit pas servir hors d’EAP. Le registre des domaines à usage spécial de l’IANA en conserve la référence.

Cette absence de découverte automatique protège une limite institutionnelle. Un commutateur ou un serveur AAA local ne doit pas déduire d’une chaîne publique qu’une autorité distante a déjà validé le terminal. Il interprète la demande selon sa propre configuration et reste responsable de l’exposition qu’il crée.

Trois pouvoirs se croisent sans se confondre. L’IETF définit un comportement commun. L’IANA enregistre des identifiants et des méthodes. L’opérateur du réseau applique une décision locale à un port, un point d’accès et un pair précis. Ni la normalisation ni l’enregistrement ne remplacent cette dernière décision.

Le même raisonnement s’applique aux sous-domaines auto-attribués permis dans l’espace v.. Ils peuvent faciliter des essais ou des extensions, mais le nom d’une organisation ne confère pas automatiquement un mandat durable. Les domaines changent de titulaire, tandis que les produits déjà livrés peuvent conserver un ancien identifiant. La durée de vie du matériel dépasse souvent celle d’une délégation commerciale.

La bonne unité de contrôle n’est donc pas seulement l’EPI. C’est la session transitoire créée lorsqu’un serveur précis accepte cet EPI sur un accès précis, sous une version précise de la politique.

Définir la limite par ce qui est permis

Une politique dite « limitée » reste vague tant que ses paquets autorisés ne sont pas connus. RFC 9965 recommande une approche positive : laisser passer uniquement le trafic attendu pour le provisionnement, bloquer tout le reste. Une liste de quelques destinations interdites ne suffit pas, car un acteur peut détourner des services restés disponibles, par exemple pour transporter des données dans DNS.

Le contrôle doit donc être observable à l’endroit où il s’exerce. Un libellé tel que « onboarding » ou « quarantaine » dans une console centrale ne prouve pas qu’un commutateur a installé la bonne ACL. Le dossier devrait conserver l’identifiant et la version du filtre, le point d’application, les protocoles et destinations autorisés, les services auxiliaires indispensables, ainsi que la règle par défaut.

RFC 9965 fournit plusieurs budgets complémentaires. La durée attendue se compte normalement en secondes ou dizaines de secondes. Un transfert volumineux paraît atypique, d’où la recommandation de limiter les octets. Le nombre de services doit rester faible. Les tentatives sont soumises à une cadence, et un pair abusif peut être bloqué. Le nombre total d’appareils simultanément en cours de provisionnement doit lui aussi être borné.

Enfin, les pairs placés dans ce réseau ne doivent pas communiquer entre eux. Cette obligation transforme le segment de provisionnement en collection de voies vers quelques serveurs, et non en petit réseau local d’appareils inconnus. Sans isolation, un pair hostile n’aurait pas besoin de sortir du périmètre pour attaquer un appareil voisin en cours d’enrôlement.

Ces budgets ne sont pas interchangeables. Une fenêtre courte n’excuse pas un accès général. Un filtre parfait sans date de fin devient un privilège persistant. Un plafond de sessions protège la capacité, mais pas les voisins. Une preuve sérieuse doit montrer que ces contrôles ont coexisté pendant toute la session.

Le Filter-Id RADIUS cité par RFC 9965 peut fournir un nom exploitable pour cette politique. Ce n’est qu’un mécanisme possible. VLAN, ACL, rôle dynamique ou objet de contrôleur peuvent convenir, à condition de conserver la version réalisée. Le nom d’un filtre sans son contenu ne permet pas de savoir si son périmètre a été élargi depuis l’audit précédent.

Le serveur doit encore se présenter

Le caractère non authentifié de la demande ne dispense pas le service de provisionnement d’être authentique. Toutes les méthodes définies sous eap.arpa doivent expliquer comment le pair authentifie le serveur, soit dans EAP, soit ensuite au moyen d’un protocole protégé comme HTTPS. Le pair doit continuer à considérer le réseau local comme hostile.

Pour portal@tls.eap.arpa, EAP-TLS peut accepter un pair non authentifié, mais le serveur doit encore être authentifié, par exemple avec son certificat. Un secret TLS prédéfini et public ne produirait pas cette asymétrie. La machine inconnue reçoit une voie minimale ; elle ne doit pas recevoir sa future configuration d’un interlocuteur tout aussi inconnu.

La séparation des rôles dans RFC 8952 est utile. Le service de provisionnement communique l’URI de l’API du portail captif. L’API décrit l’état de captivité. Le portail utilisateur permet éventuellement de satisfaire les conditions. Le dispositif d’application autorise ou bloque les paquets. Un succès côté portail ne prouve pas automatiquement la modification du dispositif d’application.

Une vue conservée par le terminal peut aussi devenir obsolète. Le terminal croit sa session proche de l’expiration alors que le réseau a changé son quota, ou inversement. L’état faisant foi doit être rapproché de l’enforcement réel, tout en notant le décalage possible entre contrôle central, équipement d’accès et client.

Le certificat produit n’est pas encore l’admission

Le parcours peut aboutir à un certificat, à une clé, à une configuration ou à l’achèvement d’une étape hors bande prévue par RFC 9140. Il peut également échouer : serveur non authentifié, méthode inconnue, délai dépassé, quota consommé, capacité saturée ou refus local.

Réduire ces cas à « terminé » détruit l’information utile. La création d’un justificatif indique qu’un artefact a été produit. Elle ne montre pas que ce justificatif correspond à la bonne fiche locale, qu’il n’a pas été révoqué, qu’il autorise le service demandé ou que l’équipement d’accès l’a accepté.

La frontière la plus nette consiste à fermer la session EPI, puis à lancer une authentification ordinaire avec le nouveau justificatif. La politique d’autorisation courante évalue alors l’identité authentifiée et décide du nouvel accès. Une transition sans rupture visible pour l’utilisateur peut rester une rupture d’autorité dans les journaux.

Lorsqu’un système change le rôle sur place, il doit conserver les mêmes preuves : ancienne session limitée, identité désormais authentifiée, décision d’autorisation, règle complète installée, retrait de l’ancienne règle et traitement d’une transition partielle. Faute de quoi, l’exception temporaire peut sembler être devenue légitime par simple élargissement.

Cette analyse ne répète pas la question de RFC 9966. Prouver la connaissance d’une clé d’amorçage n’établit pas sa chaîne de garde ; et même une garde parfaitement documentée ne prouve pas que le réseau limité a été fermé. La preuve cryptographique, l’état du provisionnement et l’admission finale ont des objets différents.

Un reçu de fermeture en sept éléments

Un opérateur peut conserver un reçu compact sans inventer un nouvel objet de protocole :

  1. Demande : EPI exact, méthode EAP, heure, authentificateur ou NAS, interface et identifiant local éphémère.
  2. Décision : acceptation ou refus, version de politique, état de capacité, catégorie de motif et service responsable.
  3. Application : filtre, segment, rôle ou ACL réellement installé, points d’application, liste positive des destinations et isolation entre pairs.
  4. Budgets : début, échéance impérative, octets, services, compteur de tentatives, limite de cadence et capacité simultanée.
  5. Authenticité du serveur : méthode de validation, référence du certificat ou de l’ancre, résultat et exception étroitement délimitée.
  6. Résultat : justificatif produit ou catégorie d’échec, durée prévue du justificatif et référence protégée sans matière secrète.
  7. Fermeture : heure du retrait ou de l’expiration, observation émise par le point d’application, sort des flux, nouvelle session authentifiée éventuelle et recherche d’états orphelins.

Le reçu doit respecter la confidentialité. Une vue publique peut montrer les durées, versions, volumes agrégés, classes d’échec et exceptions non résolues. Les identifiants stables, certificats, ports et détails de filtre restent réservés. Un hachage peut relier les deux vues sans prouver la véracité du système amont.

« Reçu de fermeture » est une proposition éditoriale de Daniel Kade. RFC 9965 n’impose aucun document de ce nom. Le standard dessine une exception interopérable ; l’opérateur doit choisir comment rendre son exercice et sa fin vérifiables.

La fin automatique peut échouer

Un TTL expiré dans une base du contrôleur ne garantit pas la disparition de la règle dans l’équipement. Une commande de retrait acceptée n’est pas encore un état de données confirmé. À l’inverse, l’équipement peut fermer la voie avant que l’orchestrateur n’enregistre la fin. Les deux temps méritent d’être conservés.

La panne ne doit jamais produire une voie plus large. Si le portail est indisponible, l’opérateur ne devrait pas ouvrir Internet pour « aider » le provisionnement. Si le service de certificats ne répond pas, le pair ne doit pas rester indéfiniment. Si une mise à jour logicielle multiplie les reprises, la cadence et la capacité doivent borner l’effet collectif.

La preuve la plus solide compare trois états : ce que la décision voulait autoriser, ce que l’équipement a effectivement appliqué, et ce qui restait après la fermeture. Un désaccord ne doit pas être masqué par un statut vert global. Il constitue l’exception à examiner.

Cette discipline rejoint le Policy Mirror de Heng Lu. Le code exécuté révèle qui peut ouvrir ou prolonger une voie en pratique ; le texte de politique montre qui devait pouvoir le faire. Leur comparaison, et non leur confusion, rend le pouvoir observable.

Limites

Les sources décrivent les protocoles, les registres et les risques annoncés. Elles ne mesurent pas le déploiement de RFC 9965, ne désignent aucun opérateur et ne démontrent aucune compromission. Les mécanismes d’application et les seuils varieront selon les réseaux.

Le reçu proposé n’est ni un certificat de conformité, ni un titre de propriété du terminal, ni un nouvel objet de l’IETF. Il ne requiert pas de rendre publique la topologie de sécurité. Sa fonction est plus modeste : empêcher qu’une exception accordée avant l’identité survive silencieusement après avoir accompli son travail.

Sources