Résumé

  • RFC 5418 décompose la sécurité CAPWAP en relations bilatérales entre station sans fil, service AAA, contrôleur d’accès et point de terminaison sans fil. La confiance ne devient pas globale parce que chaque maillon adjacent possède un justificatif.
  • Avec une clé prépartagée, l’autorisation peut rester large et limitée à une classe d’équipements : la clé ne suffit pas toujours à distinguer un contrôleur d’un point de terminaison.
  • Un certificat authentique, un canal de contrôle protégé et l’autorisation de rejoindre un déploiement sont trois faits différents. L’enrôlement, les rôles, les clés AAA et le chemin réel des données doivent être vérifiés séparément.

Une relation protégée ne vaut pas délégation

Dans le schéma de RFC 5418, la station, le service AAA, le contrôleur et le point de terminaison ne forment pas une seule relation de confiance. Chaque liaison suppose ses propres preuves ; leur enchaînement ne détermine pas quelle organisation a autorisé le WTP dans un déploiement précis. C’est cette décision d’admission que l’opérateur doit pouvoir retracer.

C’est une bonne façon d’aborder RFC 5418. Publié en mars 2009 comme document informatif, ce texte analyse le risque créé lorsque le point d’accès autonome est divisé en deux éléments : le Wireless Termination Point (WTP), situé au bord radio, et l’Access Controller (AC), placé ailleurs. Des échanges qui restaient à l’intérieur d’un seul équipement traversent désormais un réseau de couche 3. La sécurité dépend donc, selon le document, du réseau intermédiaire et de la répartition des fonctions entre le WTP et l’AC.

Le périmètre est précis : analyse des menaces dans un contexte 802.11, pas enquête sur des produits déployés, pas récit d’incident et pas norme Internet. Son apport tient à la façon dont il expose une question de contrôle qu’un schéma d’architecture peut masquer : qui est l’autre équipement, quel rôle peut-il exercer, quelles clés lui sont confiées et où circule réellement le trafic du client ?

La grille éditoriale emprunte une méthode à la Note 65 de Heng Lu, « Running-Code Primacy » : confronter les déclarations à ce que les systèmes exécutent et à ce que les opérateurs peuvent vérifier. Cette note traite de la conception des systèmes de coordination Internet ; elle ne constitue pas une règle de sécurité sans fil. Ici, elle invite simplement à ne pas substituer un diagramme ou un énoncé de politique à des preuves sur les identifiants, les rôles et le chemin de transfert installés.

CAPWAP ajoute des relations de confiance

Dans un point d’accès classique, un appareil assure le bord radio et son raccordement au réseau filaire. CAPWAP répartit cette fonction. Le WTP émet et reçoit les communications sans fil ; l’AC assure la gestion côté contrôleur et les fonctions côté réseau filaire. Cette séparation facilite la gestion centralisée et plusieurs architectures de site, mais elle crée aussi de nouveaux maillons de confiance.

L’exemple simplifié de RFC 5418 comprend au moins sept relations ou transferts de clés :

Étape Relation ou transfert Ce que cela établit dans l’exemple
1 WTP–AC Une relation de pair CAPWAP
2 AC–AAA Le lien authentifié du contrôleur au service d’authentification
3 Station–AAA L’authentification EAP et la production de matériel de clé
4 AAA → AC La remise d’une clé maîtresse pairwise au contrôleur
5 AC–station Un échange en quatre temps qui produit du matériel de clé temporaire
6 AC → WTP La remise d’une clé temporaire lorsque le chiffrement est décentralisé
7 WTP–station La sécurité de la liaison radio du client

Il ne s’agit pas d’une négociation de bout en bout. RFC 5418 précise que ces relations sont bilatérales. Le fait qu’une station fasse confiance au serveur AAA, que le serveur fasse confiance à l’AC et que l’AC fasse confiance au WTP ne signifie pas automatiquement que la station devrait faire confiance à ce WTP. Un WTP compromis pourrait conserver sa relation avec l’AC tout en présentant des informations trompeuses au client. La compromission d’un appareil dans la hiérarchie peut affecter les systèmes situés en aval.

C’est une propriété structurelle, pas l’affirmation que chaque réseau est compromis. L’enjeu est de suivre chaque identité et chaque clé jusqu’aux droits accordés, puis d’évaluer ce qu’un nœud compromis pourrait faire avec ces droits.

Ce qu’une clé commune établit — et ce qu’elle laisse ouvert

RFC 5418 sépare authentification et autorisation. L’authentification demande si le pair peut démontrer une identité ou la possession d’un justificatif. L’autorisation précise les ressources auxquelles il peut accéder et les opérations qu’il peut mener.

Pour les clés prépartagées, le document décrit une autorisation large et grossière : connaître la clé revient à être admis dans une classe de confiance. Des clés distinctes peuvent créer plusieurs classes, mais la clé d’une classe ne prouve pas à elle seule si son détenteur est un AC ou un WTP. Si le même secret fonctionne pour les deux rôles, son détenteur peut revendiquer l’un ou l’autre à moins qu’un autre contrôle ne limite l’échange.

Le risque augmente quand le secret circule plus largement que ne le suggère l’inventaire. Une clé copiée dans l’approvisionnement d’usine, les notes de préparation, la configuration d’un contrôleur et la procédure de remplacement n’est plus propre à un équipement. Elle devient une capacité opérationnelle partagée. Le risque dépend de qui peut la consulter, de la séparation réelle des classes, de sa rotation et de la validation du rôle revendiqué. RFC 5418 n’attribue pas ces pratiques à un opérateur identifié ; ce sont des questions de contrôle à examiner.

Les certificats permettent des contrôles plus précis, sans faire du simple fait d’en présenter un une politique d’enrôlement complète. RFC 5418 évoque un nom de sujet contenant l’adresse MAC et des bits Extended Key Usage propres aux rôles AC et WTP. Cela n’aide que si le pair vérifie que le nom est acceptable dans ce déploiement et applique strictement le rôle. Accepter un usage étendu générique peut effacer la séparation des rôles si aucun contrôle supplémentaire ne s’y ajoute.

Un certificat du fabricant renseigne sur l’origine du justificatif. Il ne répond pas à la question du tenant : quel AC un WTP doit-il accepter ici, et quels WTP appartiennent à ce déploiement ? RFC 5418 note explicitement que l’autorisation par certificat et la configuration sans intervention ne s’accordent pas entièrement. Son analyse suppose que le WTP peut reconnaître le bon AC et que l’AC peut reconnaître les bons WTP ; elle ne traite pas l’établissement initial de cette sélection. Cette limite doit rester visible lors des achats et des revues de sécurité.

AAA est un autre propriétaire du contrôle

Dans l’exemple simplifié, l’AC joue le rôle d’authentificateur et communique avec un serveur AAA par RADIUS ou Diameter. RFC 5418 prévient que des identifiants de longue durée, non uniques ou peu entropiques, sur la liaison AC–AAA peuvent fragiliser toute l’installation. Il recommande une liaison mutuellement authentifiée qui assure confidentialité et intégrité et renvoie aux principes de gestion des clés AAA de RFC 4962.

Cette recommandation protège un autre maillon que l’authentification WTP–AC. Une session DTLS valide ne vérifie pas automatiquement le pair AAA de l’AC. Une méthode EAP forte entre la station et AAA ne prouve pas que seul le contrôleur attendu peut recevoir les clés. Un échange radio réussi ne démontre pas que la clé a été remise au bon WTP. L’opérateur doit désigner le responsable de chaque justificatif et de chaque décision d’autorisation.

La difficulté est aussi organisationnelle. L’équipe sans fil peut gérer l’enrôlement des équipements, la sécurité peut administrer les certificats et l’équipe identité peut exploiter AAA. Chacune peut affirmer que « son lien est protégé » sans qu’aucun responsable ne vérifie la jonction entre ces assurances. Un registre utile associe à chaque relation l’émetteur du justificatif, le vérificateur, le rôle accordé et la preuve d’appartenance au déploiement.

Le tunnel de contrôle ne révèle pas le trajet des données

Les identités et le transfert de clés ne sont qu’une partie de l’architecture. RFC 5418 sépare le contrôle du transfert des données et décrit les configurations Split MAC, Local MAC et d’autres scénarios. Dans les configurations Local MAC, le WTP traite l’essentiel du travail MAC et les trames de données sont généralement pontées sur place. Les termes CAPWAP ne fixent pas strictement chaque choix de tunnelisation.

RFC 5415 précise la frontière protocolaire : les messages Discovery Request et Discovery Response restent en clair pour qu’un WTP puisse trouver des contrôleurs candidats. Les autres messages de contrôle CAPWAP doivent employer DTLS. La protection des paquets de données reste facultative et dépend de la politique de l’AC. Une relation de contrôle sécurisée ne permet donc pas de conclure que les données clients passent par l’AC, empruntent un canal de données protégé ou sont pontées localement.

Ce choix déplace le lieu d’application des règles. Un chemin centralisé peut offrir au contrôleur un point de contrôle, au prix d’un trajet supplémentaire et d’une dépendance. Le pontage local peut éviter le retour de tout le trafic vers un contrôleur distant, mais reporte la segmentation, l’inspection et la surveillance vers la périphérie et le réseau filaire connecté. Ce sont des compromis d’architecture, pas des prescriptions universelles. Il faut vérifier que le chemin effectivement choisi correspond à celui prévu par les politiques et les procédures d’incident.

Le chiffrement ne supprime pas non plus toutes les menaces. RFC 5418 examine les attaques par épuisement de ressources, l’observation passive, l’analyse de trafic ou la suppression de paquets par un acteur sur le chemin. Il mentionne aussi des attaques extérieures à CAPWAP, comme l’usurpation DNS ou DHCP et l’empoisonnement d’un cache ARP. Ces limites ne rendent pas DTLS inutile ; elles indiquent ce qu’il protège et où un autre responsable doit agir.

Une revue exploitable suit un graphe, pas une case cochée

Une revue CAPWAP utile commence par la topologie exacte et demande :

  1. Quels AC chaque WTP accepte-t-il, et comment l’appartenance au déploiement est-elle établie ?
  2. Quels WTP chaque AC accepte-t-il, et comment leurs rôles sont-ils distingués ?
  3. Les secrets partagés sont-ils assez uniques et limités pour la classe qu’ils représentent ? Qui peut les consulter, les installer, les remplacer ou les révoquer ?
  4. Quels contrôles du nom de certificat et du rôle sont réellement appliqués par l’AC et le WTP ? Que se passe-t-il si un certificat valide ne figure pas dans la liste des équipements autorisés ?
  5. Quels identifiants authentifient l’AC auprès d’AAA et où sont consignées la remise de clés et son autorisation ?
  6. Les données clients passent-elles par l’AC ou sont-elles pontées localement ? Où se trouvent le chiffrement, la segmentation, l’inspection et les journaux ?
  7. Quels risques subsistent malgré DTLS : épuisement de ressources, analyse du trafic, suppression de paquets, manipulation de la découverte ou attaque du réseau local adjacent ?

Ces questions transforment « le WLAN utilise des certificats » en propositions vérifiables. Remplacer un point d’accès devrait mettre à jour l’inventaire et l’autorisation de rôle, pas simplement confirmer la signature du fabricant. Déplacer une succursale vers le pontage local devrait déplacer avec les paquets le plan d’application des règles et d’observation. Une rotation AC–AAA ne devrait pas invalider silencieusement l’identité WTP–AC ou bloquer le chemin de secours.

Garder la limite du document

RFC 5418 est une analyse de 2009 du modèle CAPWAP et 802.11 de cette époque. Ses exemples cryptographiques et son vocabulaire ne doivent pas être repris comme instructions actuelles de configuration. RFC 5415 définit le protocole CAPWAP ; RFC 5418 étudie l’exposition créée par la séparation des fonctions du point d’accès. Aucun des deux ne prouve ce qu’un fabricant propose aujourd’hui, comment un réseau réel est configuré, ni qu’un incident a touché des utilisateurs.

L’apport reste circonscrit : un canal protégé est un maillon du graphe de confiance. La question utile n’est pas combien de maillons ont un cadenas, mais si chaque identité acceptée correspond au bon déploiement, au bon rôle et aux bons privilèges — et si le trafic client suit le chemin que l’organisation pense administrer. Posséder un justificatif et gouverner le système qu’il ouvre sont deux choses différentes.

Sources