Zusammenfassung

  • RFC 5418 beschreibt CAPWAP-Sicherheit als mehrere paarweise Beziehungen zwischen WLAN-Station, AAA-Dienst, Access Controller und Wireless Termination Point. Gesicherte Nachbarverbindungen ergeben nicht automatisch eine durchgehende Berechtigung.
  • Bei vorab geteilten Schlüsseln kann die Freigabe breit für eine Geräteklasse gelten. Der Schlüssel allein unterscheidet nicht in jedem Fall einen Access Controller von einem Wireless Termination Point.
  • Ein gültiges Zertifikat, ein geschützter Steuerkanal und die Aufnahme in ein bestimmtes Netz sind verschiedene Sachverhalte. Registrierung, Rolle, AAA-Schlüssel und tatsächlicher Datenpfad brauchen eigene Nachweise.

Wer erteilt dem WTP die Betriebsfreigabe?

Wer darf ein WTP in genau dieses Funknetz aufnehmen? Eine geprüfte Zertifikatskette beantwortet das allein nicht: Sie belegt weder die Mitgliedschaft in dieser Installation noch den Umfang der AC- oder WTP-Rolle. RFC 5418 legt damit eine Zuständigkeitsfrage offen, die technische Identitätsprüfung und betriebliche Freigabe auseinanderhält.

RFC 5418 bietet einen konkreten Rahmen für diese Unterscheidung. Das 2009 veröffentlichte Informational-Dokument untersucht die zusätzliche Angriffsfläche, wenn ein eigenständiger Zugangspunkt in zwei Netzkomponenten aufgeteilt wird: den Wireless Termination Point (WTP) am Funkrand und den Access Controller (AC) an einem anderen Ort. Interaktionen, die zuvor innerhalb eines Geräts stattfanden, laufen nun über ein Layer-3-Netz. Die Sicherheit hängt laut Dokument vom vermittelnden Netz und davon ab, wie die Funktionen zwischen WTP und AC verteilt werden.

Der Geltungsbereich ist eng: eine Bedrohungsanalyse für CAPWAP mit IEEE 802.11. Das Dokument ist weder eine Bestandsaufnahme installierter Produkte noch ein Vorfallbericht oder Internet-Standard. Sein Nutzen liegt darin, Fragen aufzuteilen, die ein Architekturdiagramm leicht zu einer einzigen grünen Verbindung zusammenzieht: Wer ist das Gegenüber? Welche Rolle darf es übernehmen? Welche Schlüssel erhält es? Wo fließen die Clientdaten tatsächlich?

Die redaktionelle Methode entlehnt diese Analyse Heng Lus Note 65 „Running-Code Primacy“: Aussagen müssen mit dem abgeglichen werden, was Systeme wirklich ausführen und Betreiber nachweisen können. Die Note behandelt die Gestaltung von Internet-Koordinationssystemen und ist keine WLAN-Sicherheitsvorgabe. Hier bedeutet sie, dass eine Zeichnung oder Richtlinie keinen Beleg für die installierten Identitäten, Rollenprüfungen, Controller-Beziehungen und Weiterleitungswege ersetzt.

CAPWAP fügt Vertrauensbeziehungen hinzu

Beim herkömmlichen Zugangspunkt verbindet ein Gerät den Funkrand mit dem kabelgebundenen Netz. CAPWAP trennt diese Aufgaben: Der WTP sendet und empfängt Funkverkehr; der AC übernimmt Verwaltung und Funktionen auf der kabelgebundenen Seite. Das erleichtert zentrale Verwaltung und unterschiedliche Standortarchitekturen, schafft aber zusätzliche Vertrauensbeziehungen.

Das vereinfachte Beispiel in RFC 5418 enthält mindestens sieben Beziehungen oder Schlüsselübergaben:

Schritt Beziehung oder Übergabe Was sie im Beispiel belegt
1 WTP–AC Eine CAPWAP-Peerverbindung
2 AC–AAA Die authentisierte Verbindung des Controllers zum Authentisierungsdienst
3 Station–AAA EAP-Authentisierung und Erzeugung von Schlüsselmaterial
4 AAA → AC Übergabe eines Pairwise Master Key an den Controller
5 AC–Station Vier-Wege-Handshake mit temporärem Schlüsselmaterial
6 AC → WTP Übergabe eines temporären Schlüssels bei dezentraler Verschlüsselung
7 WTP–Station Schutz der Funkverbindung des Clients

Das ist kein einzelner Ende-zu-Ende-Austausch. RFC 5418 betont, dass es paarweise Vertrauensbeziehungen sind. Eine Station kann dem AAA-Server vertrauen, AAA dem AC und der AC dem WTP, ohne dass die Station diesem WTP automatisch vertrauen sollte. Ein kompromittierter WTP kann seine Verbindung zum AC aufrechterhalten und zugleich irreführende Netzwerkinformationen an die Station übermitteln. Ein kompromittiertes Gerät in der Hierarchie kann nachgelagerte Geräte beeinträchtigen.

Das beschreibt eine strukturelle Möglichkeit, keinen Vorfall und keine Aussage, jedes WLAN sei kompromittiert. Eine Prüfung muss jede Identität und jeden Schlüssel bis zu den gewährten Rechten verfolgen und fragen, was ein kompromittierter Knoten damit tun könnte.

Was ein gemeinsamer Schlüssel belegt – und was offenbleibt

RFC 5418 unterscheidet Authentisierung von Autorisierung. Authentisierung fragt, ob ein Gegenüber eine Identität oder den Besitz eines Nachweises belegen kann. Autorisierung legt fest, auf welche Ressourcen und Handlungen es Zugriff erhält.

Bei vorab geteilten Schlüsseln beschreibt das Dokument eine breite, grobe Berechtigung: Wer den Schlüssel kennt, gilt als vertrauenswürdig für die zugehörige Geräteklasse. Getrennte Schlüssel können mehrere Klassen bilden, doch der Klassenschlüssel weist für sich genommen nicht nach, ob sein Besitzer AC oder WTP ist. Verwenden beide Rollen dasselbe Geheimnis, kann dessen Besitzer eine der beiden Rollen beanspruchen, solange keine weitere Prüfung den Austausch begrenzt.

Das Risiko wächst, wenn sich ein Geheimnis weiter verteilt, als es das Geräteverzeichnis vermuten lässt. Wird derselbe Schlüssel in Werksbereitstellung, Installationsnotizen, Controller-Konfiguration und Austauschverfahren kopiert, gehört er nicht mehr zu einem einzelnen Gerät, sondern wird zu einer geteilten Betriebsberechtigung. Entscheidend ist, wer ihn abrufen kann, wie strikt Geräteklassen getrennt sind, wie der Schlüssel erneuert wird und ob das Gegenüber die behauptete Rolle prüft. RFC 5418 schreibt keinem bestimmten Betreiber solche Praktiken zu; es sind Kontrollfragen an den Betreiber.

Zertifikate ermöglichen feinere Prüfungen, doch ihre bloße Vorlage ist keine vollständige Aufnahmeregel. RFC 5418 nennt einen Subject-Namen mit der MAC-Adresse und Extended-Key-Usage-Bits zur Unterscheidung von AC und WTP. Das hilft nur, wenn das Gegenüber prüft, ob der Name in dieser Installation zulässig ist und die Rolle strikt erzwingt. Ein allgemeiner Extended-Key-Usage-Zweck kann die Trennung aufheben, sofern keine zusätzlichen Namensprüfungen stattfinden.

Ein Herstellerzertifikat belegt, wer den Nachweis ausgegeben hat. Es beantwortet nicht die Betreiberfrage: Welchen AC soll der WTP in diesem Netz akzeptieren, und welche WTP gehören zu dieser Installation? RFC 5418 hält ausdrücklich fest, dass Zertifikatsautorisierung und Inbetriebnahme ohne Konfiguration nicht vollständig zusammenpassen. Die Analyse setzt voraus, dass WTP und AC den jeweils richtigen Gegenpart kennen; wie diese Auswahl zustande kommt, bleibt außerhalb ihres Umfangs. Diese Annahme muss in Beschaffung und Sicherheitsprüfung sichtbar bleiben.

AAA braucht einen eigenen Verantwortlichen

Im vereinfachten Beispiel ist der AC der Authentisierer und kommuniziert über RADIUS oder Diameter mit einem AAA-Server. RFC 5418 warnt, dass nicht eindeutige oder schwache Langzeit-Zugangsdaten auf der Verbindung AC–AAA die Sicherheit des gesamten CAPWAP-Betriebs ernsthaft beeinträchtigen können. Es empfiehlt gegenseitige Authentisierung sowie Vertraulichkeit und Integrität und verweist auf RFC 4962 für die Schlüsselverwaltung bei AAA.

Diese Empfehlung schützt eine andere Verbindung als WTP–AC. Eine gültige DTLS-Sitzung zwischen WTP und AC authentisiert nicht automatisch den AAA-Partner des Controllers. Ein starkes EAP-Verfahren zwischen Station und AAA belegt nicht, dass nur der vorgesehene Controller resultierendes Schlüsselmaterial erhält. Ein erfolgreicher Funk-Handshake beweist ebenso wenig, dass der richtige WTP den Schlüssel bekam. Für jeden Nachweis und jede Berechtigungsentscheidung braucht es einen benannten Eigentümer.

Das ist auch eine Organisationsfrage. Das WLAN-Team kann Geräte aufnehmen, die Sicherheitsabteilung Zertifikate verwalten und das Identitätsteam AAA betreiben. Jede Gruppe kann ihre Verbindung als geschützt melden, während niemand prüft, wie die Zusicherungen ineinandergreifen. Ein brauchbares Verzeichnis verbindet jede Beziehung mit dem Aussteller des Nachweises, der prüfenden Stelle, der gewährten Rolle und dem Beleg für die Zugehörigkeit zur Installation.

Der Steuerkanal zeigt nicht den Datenweg

Identität und Schlüsselübergabe beschreiben nicht die ganze Architektur. RFC 5418 unterscheidet Steuerung und Nutzdatenweiterleitung und behandelt Split MAC, Local MAC und weitere Szenarien. Bei Local MAC verarbeitet der WTP den größten Teil der MAC-Funktionen; Datenrahmen werden meist vor Ort ins kabelgebundene Netz überbrückt. Die CAPWAP-Begriffe schreiben nicht jedes Detail des Datentunnels vor.

RFC 5415 legt die Protokollgrenze fest: Discovery Request und Discovery Response bleiben ungeschützt, damit ein WTP Controller finden kann. Andere CAPWAP-Steuernachrichten müssen DTLS verwenden. Der Schutz von Datenpaketen ist dagegen optional und hängt von der AC-Richtlinie ab. Eine geschützte Steuerverbindung beweist daher weder, dass Clientdaten den AC durchlaufen, noch dass sie einen geschützten Datentunnel nutzen oder vor Ort weitergeleitet werden.

Die Wahl verschiebt zugleich den Ort, an dem Richtlinien wirken. Zentrale Weiterleitung kann dem Controller einen Kontrollpunkt geben, erzeugt aber zusätzliche Wege und Abhängigkeiten. Lokale Überbrückung erspart, den gesamten Verkehr zu einem entfernten Controller zurückzuführen, verlagert Segmentierung, Prüfung und Beobachtung aber näher an den Rand und das angeschlossene Kabelnetz. Das sind Architekturabwägungen, keine allgemeingültigen Empfehlungen. Zu prüfen ist, ob der tatsächliche Weg zu Richtlinien und Notfallplan passt.

Auch Verschlüsselung beseitigt nicht jede Bedrohung. RFC 5418 behandelt Ressourcenerschöpfung, passive Beobachtung, Verkehrsanalyse und Paketunterdrückung durch einen Angreifer im Pfad. Außerdem nennt es Angriffe außerhalb von CAPWAP wie DNS- oder DHCP-Manipulation und ARP-Cache-Vergiftung. Diese Grenzen entwerten DTLS nicht; sie zeigen, wofür es zuständig ist und wo ein anderer Verantwortlicher gebraucht wird.

Eine Prüfung folgt dem Vertrauensgraphen

Eine wirksame CAPWAP-Prüfung beginnt mit der tatsächlichen Topologie und fragt:

  1. Welche ACs akzeptiert jeder WTP, und wie wird die Zugehörigkeit zur Installation belegt?
  2. Welche WTPs akzeptiert jeder AC, und wie werden die Rollen getrennt?
  3. Sind gemeinsame Schlüssel für ihre Geräteklasse ausreichend eindeutig und eng begrenzt? Wer kann sie abrufen, installieren, erneuern oder widerrufen?
  4. Welche Namens- und Rollenprüfungen erzwingen AC und WTP wirklich? Was passiert bei einem gültigen Zertifikat, das nicht in der Freigabeliste steht?
  5. Welche Zugangsdaten nutzt der AC gegenüber AAA, und wo werden Schlüsselübergabe und Autorisierung festgehalten?
  6. Laufen Clientdaten über den AC oder werden sie lokal überbrückt? Wo befinden sich Verschlüsselung, Segmentierung, Prüfung und Protokollierung?
  7. Welche Risiken bleiben trotz DTLS: Ressourcenerschöpfung, Verkehrsanalyse, Paketunterdrückung, manipulierte Suche oder ein Angriff auf das angrenzende LAN?

So wird aus „das WLAN nutzt Zertifikate“ eine Reihe prüfbarer Aussagen. Beim Austausch eines Zugangspunkts müssen Verzeichnis und Rollenfreigabe aktualisiert werden; die Herstellersignatur allein genügt nicht. Wird eine Niederlassung auf lokale Überbrückung umgestellt, müssen Richtlinien und Beobachtung dem Paketpfad folgen. Beim Wechsel eines AC–AAA-Schlüssels ist zu prüfen, dass WTP–AC-Identität und Rückfallweg nicht versehentlich ausfallen.

Die Grenze des Dokuments bleibt bestehen

RFC 5418 ist eine Analyse des CAPWAP- und 802.11-Entwurfs von 2009. Seine kryptografischen Beispiele und Begriffe sind keine heutige Konfigurationsanleitung. RFC 5415 definiert CAPWAP; RFC 5418 analysiert die zusätzliche Angriffsfläche, die durch die Aufteilung der Zugangspunktfunktionen entsteht. Keines der Dokumente belegt aktuelle Herstellerprodukte, die Konfiguration eines bestimmten Netzes oder einen konkreten Vorfall.

Der bleibende analytische Punkt ist enger: Ein geschützter Kanal ist eine Kante in einem Vertrauensgraphen. Entscheidend ist nicht, wie viele Kanten ein Schloss-Symbol tragen, sondern ob jede akzeptierte Identität zur richtigen Installation, Rolle und Berechtigung gehört — und ob die Clientdaten den Weg nehmen, den die Organisation zu kontrollieren glaubt. Ein Zugangsnachweis zu besitzen ist nicht dasselbe, wie das dadurch geöffnete System zu beherrschen.

Quellen