Résumé

  • La chaîne de certificats, CertificateVerify et Finished attestent des faits cryptographiques définis par EAP-TLS. Ils n’installent ni VLAN ni filtre et n’ouvrent aucun port contrôlé.
  • RFC 3748 prévoit qu’une authentification peut réussir avant un refus d’autorisation, ou qu’une autorisation peut être accordée alors que l’authentificateur ne peut pas fournir le service demandé.
  • La preuve exploitable est une chaîne : identité certifiée, résultat EAP, décision AAA, droit du NAS à recevoir les clés, application locale de la politique, puis trafic observé.

Le succès qui s’arrête à 8 h 14

À 8 h 14 min 02 s, dans une scène analytique construite, le poste et le serveur EAP valident leurs certificats. Les signatures CertificateVerify établissent la possession des clés privées. Les messages Finished confirment le même transcript protégé. Le tableau PKI devient vert.

Une seconde plus tard, le service AAA associe l’identité certifiée au NAS, au port et à la politique du jour. Il renvoie une autorisation conditionnelle : rôle donné, VLAN précis, filtre déterminé. Le tableau de politique devient vert à son tour.

À 8 h 14 min 04 s, le commutateur constate que le VLAN demandé n’existe pas dans le contexte de transfert local. Il ne peut exécuter l’autorisation. Le port contrôlé reste fermé ; aucun bail, aucune configuration IPv6 et aucun échange applicatif ne suivent.

La chronologie ne décrit ni produit ni panne réelle. Elle met en scène une séparation que RFC 5216, RFC 3748 et RFC 3579 conservent délibérément. Les deux premiers voyants ne mentent pas. C’est le libellé « accès réussi » qui leur attribue une autorité qu’ils n’ont pas.

Une cérémonie cryptographique aux limites nettes

RFC 5216 définit EAP-TLS comme une méthode EAP utilisant TLS pour l’authentification mutuelle par certificats, la négociation protégée, l’échange de clés et la dérivation de matière cryptographique. La validation de chemin répond à une question de confiance selon une politique donnée. CertificateVerify répond à une question de possession de clé. Finished lie les parties au transcript et aux secrets négociés.

Ces réponses sont fortes parce qu’elles sont précises. Le certificat peut offrir une identité authentifiée à un moteur de politique ; il ne contient pas l’état instantané d’un port, la capacité d’un segment, le résultat d’installation d’une ACL ou la santé d’une application.

L’ensemble actuel ne se réduit d’ailleurs pas au texte de 2008. RFC 8996 a déprécié TLS 1.0 et 1.1. RFC 9190 définit EAP-TLS avec TLS 1.3 et modifie échanges, dérivation, confidentialité et reprise. RFC 9965 ajoute le cadre eap.arpa. Le statut de norme ne constitue pas une mesure d’adoption, et aucune mise à jour ne transforme la cryptographie en sonde de service.

La section Autorisation de RFC 9190 vaut pour EAP-TLS en général. Elle exige que décision et comptabilité reposent sur des données authentifiées — certificat, identité PSK, état de reprise — plutôt que sur l’EAP-Response/Identity extérieur, falsifiable. Elle permet aussi au serveur de considérer des informations non EAP : NAS, MAC, adresse IP, port ou SSID. L’authentification fournit donc une entrée au jugement ; elle n’absorbe pas ce jugement.

Le résultat EAP ne synchronise pas tous les acteurs

RFC 3748 explique pourquoi le succès de méthode ne garantit pas l’accord sur l’autorisation. Un proxy AAA peut décider sans que le serveur EAP le voie. Le serveur AAA peut attendre la fin d’une authentification valide avant de refuser l’accès. Il peut aussi accorder l’accès alors que l’authentificateur manque temporairement de ressources.

Dans le premier cas, l’autorité se trouve ailleurs. Dans le deuxième, l’identité est établie mais la permission manque. Dans le troisième, la permission existe mais l’exécution locale manque. Un compteur unique efface précisément l’information nécessaire au diagnostic.

RFC 4137 formalise les machines d’état EAP et leurs signaux à la couche inférieure. Une sortie eapSuccess reste la conclusion d’une machine. Elle n’inspecte pas spontanément la table de VLAN, l’attribution d’adresse ni le parcours applicatif.

Posséder la clé n’accorde pas son usage

RFC 5247 divise le système en phases. La méthode EAP dérive MSK et EMSK entre le pair et le serveur. AAA transporte une matière appropriée vers l’authentificateur. Un protocole d’association sûre démontre ensuite la possession et dérive des clés transitoires.

Le cadre formule la limite essentielle : prouver la possession de matière de clé ne prouve pas nécessairement l’autorisation de la détenir. Une poignée de main locale peut confirmer que pair et authentificateur partagent la bonne valeur sans établir que le backend a autorisé ce NAS à la recevoir.

RFC 4962 exige donc l’autorisation du pair et de l’authentificateur. RFC 4017 distingue authentification mutuelle, robustesse des clés et autorisation. RFC 5295 limite les dérivations EMSK par usage et domaine. Une valeur secrète a une portée ; elle n’est pas un permis universel.

Access-Accept reste une consigne conditionnelle

Dans une architecture courante, le NAS relaie EAP vers RADIUS. RFC 3579 fait d’Access-Accept et d’Access-Reject des résultats propres, différents du paquet EAP transporté. Le Reject impose le refus. L’Accept termine la phase d’authentification et transporte éventuellement des attributs d’autorisation.

Le NAS doit encore pouvoir offrir le service. S’il reçoit un Accept demandant une prestation indisponible, RFC 3579 lui impose de le traiter comme un Reject. RFC 3580 traite aussi les conflits entre type RADIUS et contenu EAP : le contrôle d’accès doit suivre la décision RADIUS, non un EAP-Success isolé.

Le journal backend prouve ainsi l’émission d’une consigne. Le journal du NAS doit prouver la reconnaissance des attributs, la résolution du rôle ou du VLAN, l’installation des filtres, l’association sûre et l’ouverture du port. Même cette ouverture ne garantit ni DHCP, ni découverte de voisins, ni DNS, ni application.

Le contexte du réseau a sa propre provenance

RFC 6677 répond au « lying NAS » : un authentificateur de passage peut montrer une propriété au pair et une autre à l’infrastructure AAA. Les channel bindings comparent les perceptions du réseau dans un canal protégé.

Ce mécanisme existe justement parce que le certificat du poste n’authentifie pas le SSID, le port, le fournisseur visité ou la nature du service. Ces faits proviennent d’acteurs différents. Même une liaison de canal correcte ne démontre pas que le VLAN transférera ensuite les paquets.

RFC 7542 encadre les identifiants NAI ; RFC 9427 adapte les méthodes EAP fondées sur TLS à TLS 1.3. Ils améliorent les raccords de preuve, sans abolir les raccords.

La reprise ne fige pas les privilèges

RFC 9190 considère une reprise TLS 1.3 acceptée comme authentifiée et rattachée à une authentification antérieure. Il avertit néanmoins qu’une session reprise ne doit pas recevoir plus de privilèges que prévu à l’origine.

Un ticket peut rester cryptographiquement valable pendant qu’un certificat est révoqué, qu’un rôle change, qu’un NAS déménage ou qu’un VLAN disparaît. Validité du certificat, révocation, durée du ticket, durée d’autorisation, état du port et santé du service sont six horloges.

La vérification de révocation renforcée et l’agrafage OCSP répondent en partie au problème du poste sans Internet avant EAP. Ce bootstrap bien conçu ne certifie pas ce qui se passe après l’ouverture du réseau.

Un registre de preuves plutôt qu’un résumé trompeur

Le reçu certificat conserve ancre, hachages de chaîne, nom validé, période et verdict de révocation. Le reçu TLS conserve version, suite, CertificateVerify et Finished sans exposer les secrets. Le reçu EAP conserve méthode, indication protégée et résultat.

Le reçu AAA conserve identité authentifiée, NAS, contexte, version de politique, Accept ou Reject et attributs exacts. Le reçu de transport de clé montre quel authentificateur avait le droit de recevoir quelle matière. Le NAS produit enfin son reçu d’exécution : attributs compris, VLAN présent, ACL installée, association sûre et état du port. Adresse, DNS et premier échange applicatif terminent la chaîne.

Les échecs intermédiaires doivent rester visibles. « Certificat valide, autorisation refusée » est cohérent. « Accept reçu, service indisponible » est exploitable. « Port ouvert, application en panne » n’annule pas l’authentification. Une architecture honnête ne redoute pas ces phrases ; elle en a besoin.

Sources

  1. RFC 5216
  2. RFC 5216 sur Datatracker
  3. Statut de RFC 5216
  4. Historique de RFC 5216
  5. Errata de RFC 5216
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption