Résumé

  • Une méthode EAP peut authentifier correctement un pair alors que la politique, les attributs AAA, l’équipement d’accès ou la couche de liaison refusent encore la session.
  • Un dossier exploitable conserve séparément la transcription de méthode, le résultat EAP, le paquet RADIUS, la décision d’autorisation, le transfert de clés, l’association sécurisée et la première connectivité utile.

Dans un centre d’assistance, « authentification réussie » ressemble souvent à la fin du diagnostic. En réalité, cette phrase peut désigner la réussite d’une méthode cryptographique, la réception d’un paquet EAP Success, un Access-Accept RADIUS ou l’ouverture effective d’un port contrôlé. Ces événements peuvent se suivre ; ils ne se remplacent pas.

La RFC 3748, publiée sur le Standards Track en 2004, définit l’Extensible Authentication Protocol. Bernard Aboba la signe avec Larry Blunk, John Vollbrecht, James Carlson et Henrik Levkowetz. Cette pluralité interdit d’en faire l’invention solitaire d’un homme. Elle rappelle surtout le choix d’architecture : EAP est un cadre pour des méthodes d’authentification, pas un moteur universel d’autorisation réseau.

Le pair dialogue avec un authentificateur situé sur le lien. Le serveur EAP termine la méthode. Dans une architecture pass-through, ce serveur réside dans l’infrastructure AAA, parfois loin du point d’accès, tandis que l’authentificateur relaie des messages dont il ne connaît pas le mécanisme interne. La preuve d’identité et l’ouverture du chemin de données relèvent donc de composants différents.

La RFC indique qu’un pair authentifié peut être privé d’accès pour défaut d’autorisation, par exemple lorsqu’une limite de sessions est atteinte. Des mandataires AAA peuvent aussi influer sur la décision. Le résultat protégé d’une méthode dit ce que les deux extrémités de cette méthode ont vérifié. Il ne publie pas automatiquement la politique commerciale, le VLAN attribué, la capacité locale de l’équipement ni l’état du port.

Un paquet final volontairement étroit

Après l’achèvement réussi d’une méthode, l’authentificateur envoie un paquet EAP de code 3. Il ne contient aucune donnée supplémentaire. Il n’est ni acquitté ni retransmis. Dans certaines conditions, le pair peut s’appuyer sur une indication de succès de la couche basse lorsque ce paquet s’est perdu. Une capture isolée ne suffit donc ni à reconstruire toute la décision, ni à conclure à un échec par simple absence.

Le protocole exige aussi d’ignorer un succès préfabriqué envoyé dès la connexion si la méthode n’autorise pas sa conclusion. Cette contrainte empêche un faux authentificateur de court-circuiter l’échange. Elle montre pourquoi le code visible doit rester attaché à l’état de la méthode qui le précède.

Un EAP Success n’enregistre pas les attributs d’autorisation, l’installation d’une clé ou le passage du port à l’état autorisé. Il ne prouve pas davantage l’obtention d’une adresse IP ni la réussite d’un premier flux applicatif. Ces constats appartiennent aux couches suivantes.

Le verdict RADIUS appartient à un autre registre

Dans la RFC 3579, Aboba et P. Calhoun décrivent le transport d’EAP par RADIUS. Le NAS relaie les messages jusqu’à recevoir Access-Accept ou Access-Reject. Sa décision de contrôle d’accès doit reposer sur le type de paquet RADIUS, jamais sur le contenu du paquet EAP encapsulé.

Les combinaisons contradictoires illustrent le risque. Un Access-Reject contenant EAP Success ne devrait pas être émis ; s’il arrive, le NAS refuse l’accès alors que le pair peut croire son authentification réussie. Un Access-Accept associé à EAP Failure divise les conclusions dans l’autre sens. Le NAS ne doit pas fabriquer un nouveau paquet pour masquer le conflit. Il faut conserver les deux reçus et traiter leur désaccord.

Access-Accept clôt la phase d’authentification, pas toute l’expérience réseau. Il peut transporter un service, un filtre, un VLAN ou une limite. Si le NAS reconnaît un service mais ne sait pas le fournir, l’échec est le résultat correct. Le même compte peut recevoir des autorisations différentes selon l’authentificateur, sa capacité, la localisation, l’itinérance ou l’état de session.

Une clé exportée n’est pas encore un canal utilisable

La RFC 5247, cosignée par Aboba, Dan Simon et P. Eronen, décompose le passage aux données. Une méthode produit éventuellement une Master Session Key. L’infrastructure AAA transporte une partie du matériel de clé. Un protocole d’association sécurisée de couche basse établit ensuite les clés transitoires employées par le trafic.

La réussite de la première étape ne prouve aucune des deux suivantes. Le MSK peut être destiné au mauvais authentificateur, dépasser sa portée autorisée, ne pas donner la bonne clé transitoire ou ne jamais mener à une association terminée. Les identifiants du pair et du serveur, le destinataire de la clé, sa portée et l’identifiant d’association doivent rester consultables.

La RFC 3748 demande en outre de lier la protection paquet par paquet aux entités ayant achevé EAP. Sans intégrité, authentification et anti-rejeu de couche basse reliées aux clés dérivées, le trafic ultérieur peut être modifié ou rejoué malgré une transcription d’authentification correcte.

Des identifiants valides sur le mauvais réseau

Un même jeu d’identifiants peut servir plusieurs services. Un point d’accès malveillant ou mal configuré peut alors annoncer un réseau et conduire le pair vers un autre. La RFC 6677 traite ce problème de NAS ou fournisseur mensonger. Le pair transmet sous protection ce qu’il a observé ; le serveur EAP compare ces données avec les déclarations et références de l’authentificateur.

Le channel binding ne signifie pas que le client connaît magiquement le réseau. Il produit une comparaison entre quatre éléments : annonce vue, affirmation du NAS, attente du serveur et méthode qui protège l’échange. Supprimer l’un d’eux transforme un résultat vérifiable en badge vague.

La RFC 5216 montre la même frontière avec EAP-TLS. Une chaîne de certificats valide doit encore représenter des identités appropriées et autorisées pour cet usage dans ce déploiement. La validité cryptographique nourrit l’autorisation ; elle ne la remplace pas.

Le reçu d’accès complet

Le journal commence par le réseau découvert, l’intention du pair, l’identité du NAS et le port. Il poursuit avec la méthode choisie, sa transcription, son résultat protégé, les identifiants exportés, le résultat EAP externe, le type RADIUS, les attributs et la décision locale. Viennent ensuite l’export et le destinataire des clés, l’association sécurisée, le port contrôlé, la configuration IP, la première connectivité et la comptabilité de session.

Cette chaîne permet de distinguer un mauvais secret d’une politique restrictive, un Access-Accept d’un service non pris en charge, une clé calculée d’une clé installée et une liaison ouverte d’un accès réellement utilisable.

Sources