Zusammenfassung

  • Eine erfolgreiche EAP-Methode kann ein eng begrenztes Authentisierungsergebnis liefern, während Zugangsrichtlinie, AAA-Attribute, Authenticator und Datenpfad der unteren Schicht jeweils noch anders entscheiden können.
  • Ein belastbarer Zugangsbeleg hält Methodenergebnis, äußeres EAP-Ergebnis, RADIUS-Paket, Autorisierung, Schlüsselübergabe, sichere Assoziation und erste nutzbare Verbindung getrennt fest.

Der aufschlussreichste EAP-Fehler beginnt nicht zwingend mit einem falschen Passwort. Ein Peer kann eine starke zertifikatsbasierte Methode abschließen, das Backend kann den Identitätsnachweis annehmen und das Protokoll kann Erfolg melden. Trotzdem erhält die Person keinen Netzzugang: Eine Sitzungsgrenze verhindert die Autorisierung, das angeforderte VLAN wird nicht unterstützt, ein Schlüssel landet beim falschen Authenticator oder die sichere Assoziation der unteren Schicht kommt nicht zustande. „Authentisierung erfolgreich“ bleibt auf einer Ebene wahr und beschreibt die Sitzung als Ganzes dennoch gefährlich unvollständig.

Diese Trennung ist im RFC 3748 angelegt, der Standards-Track-Spezifikation des Extensible Authentication Protocol aus dem Jahr 2004. Bernard Aboba ist einer von fünf Autoren, neben Larry Blunk, John Vollbrecht, James Carlson und dem Editor Henrik Levkowetz. Die gemeinsame Urheberschaft ist wichtig: EAP wurde bewusst als Authentisierungsrahmen entworfen, nicht als universelles System für Zugangskontrolle.

Ein Methodenerfolg ist ein begrenzter Beleg

EAP unterscheidet Peer, Authenticator und EAP-Server. Bei Pass-through-Betrieb reicht das Zugangsgerät den EAP-Austausch über AAA an ein Backend weiter, ohne die Methode selbst zu beenden. Der Server kann daher wissen, dass die Methode erfolgreich war, während das Zugangsgerät noch eine andere Nachricht braucht, um zu erfahren, welcher Dienst erlaubt ist und ob es ihn überhaupt bereitstellen kann.

Die äußere EAP-Success-Nachricht trägt Code 3, aber keine zusätzlichen Daten. Der Peer bestätigt sie nicht, und sie wird nicht erneut übertragen. RFC 3748 verlangt zudem, dass ein Peer ein vorgefertigtes Success verwirft, wenn es vor dem für die Methode erlaubten Abschluss eintrifft. Unter bestimmten Bedingungen kann eine Erfolgsmeldung der unteren Schicht eine verlorene äußere Nachricht ersetzen. Schon diese Eigenschaften zeigen: Das bloße Auftauchen von „Success“ beweist keinen offenen Datenpfad.

Die Spezifikation sagt ausdrücklich, dass ein authentisierter Peer aufgrund einer Richtlinie abgewiesen werden kann, etwa wegen eines Sitzungslimits. Auch AAA-Proxys auf dem Weg können die Autorisierung beeinflussen. Der Identitätsnachweis beantwortet, wer im Rahmen einer Methode akzeptiert wurde. Ob dieser Akteur jetzt genau diesen Dienst nutzen darf, ist eine andere Entscheidung.

Beim NAS entscheidet der RADIUS-Pakettyp

RFC 3579 zieht eine scharfe betriebliche Grenze: Das NAS muss seine Zugangsentscheidung ausschließlich auf den Typ des RADIUS-Pakets stützen – Access-Accept oder Access-Reject – und nicht auf das darin gekapselte EAP-Ergebnis. Ein Server sollte kein Access-Reject mit EAP Success senden. Erhält ein NAS diese widersprüchliche Kombination dennoch, verweigert es den Zugang, obwohl der Peer die Authentisierung womöglich für erfolgreich hält. Das ist ein Fehlerbild, das sichtbar gemacht werden muss, kein normaler Pfad.

Auch Access-Accept ist nicht das Ende. Das Paket kann Diensttyp, VLAN, Filter oder Sitzungslimits enthalten. Wird ein bekannter Dienst verlangt, den das NAS nicht unterstützt, muss der Vorgang scheitern, statt stillschweigend einen anderen Zugang zu gewähren. Die Authentisierungsphase kann beendet sein, während die Ausführung der Autorisierung weiterhin von lokaler Fähigkeit und überprüfbarem Zustand abhängt.

Ein Betriebsbildschirm braucht deshalb mindestens vier getrennte Zeilen: Ergebnis der EAP-Methode, äußeres EAP-Ergebnis, RADIUS-Pakettyp und lokale Durchsetzungsentscheidung. Eine einzige grüne Anzeige löscht die Unterschiede zwischen ungültigem Nachweis, Richtlinienablehnung, nicht unterstütztem Attribut und widersprüchlicher Nachricht.

Ein exportierter Schlüssel ist noch kein Datenpfad

RFC 5247 verlängert die Kette vom Methodenergebnis zur EAP-Schlüsselverwaltung. Eine Methode kann einen MSK exportieren. Der Export beweist jedoch nicht, dass der Schlüssel den richtigen Empfänger erreichte, an Authenticator und Sitzung gebunden wurde, dass transiente Schlüssel entstanden, installiert wurden oder die sichere Assoziation vollendet ist. Jeder Übergang hat einen eigenen Geltungsbereich und braucht einen eigenen Beleg.

Die Sicherheitsanforderungen des RFC 3748 verlangen, abgeleitete Schlüssel an die Entitäten zu binden, die die Authentisierung abgeschlossen haben. Fehlt diese Bindung, kann das Authentisierungsprotokoll sauber aussehen, während der Datenverkehr für Veränderung, Täuschung oder Wiederholung offen bleibt. Ein Statusfeld „MSK vorhanden“ genügt also nicht; nach Empfänger und Kontext müssen Portzustand und tatsächlicher Verkehr folgen.

RFC 5216 zeigt dieselbe Grenze für EAP-TLS. Die Validierung des Zertifikatspfads ist notwendig. Zusätzlich muss die Implementierung entscheiden, ob die dargestellten Identitäten im konkreten Einsatz passend und für EAP-TLS autorisiert sind. Kryptografische Gültigkeit ist ein Eingangswert der Autorisierung, kein universeller Ersatz für sie.

Selbst der angekündigte Netzname kann falsch sein

Ein Nachweis kann für mehrere Dienste gelten. Daraus entsteht ein weiteres Risiko: Ein böswilliger oder falsch konfigurierter Authenticator kann ein Netz ankündigen und den Peer mit einem anderen Dienst verbinden. RFC 6677 beschreibt dies als Problem des lügenden NAS beziehungsweise Providers. Beim Channel Binding sendet der Peer seine geschützte Beobachtung des angekündigten Dienstes an den EAP-Server. Dieser vergleicht sie mit den Angaben des Authenticators und seinen eigenen Erwartungen.

Channel Binding ist kein pauschales Versprechen, der Peer „kenne das Netz“. Es ist ein Vergleich benannter Eingaben mit einem Ergebnis. Der Nachweis sollte festhalten, was der Peer sah, was das NAS behauptete, was das Backend erwartete und welche geschützte Methode den Vergleich trug. Ohne diese Angaben können gültige Zugangsdaten und eine starke Methode beim falschen Dienst enden.

Der Zugangsbeleg braucht eine feste Reihenfolge

Ein brauchbares Betriebsjournal beginnt vor der Authentisierung: entdeckter Netzname, Absicht des Peers, Identität des Authenticators und Zugangsport. Danach folgen gewählte EAP-Methode, geschütztes Methodenergebnis, Peer- und Serveridentitäten, äußeres EAP-Ergebnis, RADIUS-Pakettyp, Autorisierungsattribute und die lokale Unterstützungsentscheidung des NAS. Erst dann kommen Schlüsselexport, Empfänger, Protokoll der sicheren Assoziation und Kennungen installierter Schlüssel. Portzustand, IP-Konfiguration, erster nutzbarer Verkehr und spätere Abrechnung oder Trennung schließen die Kette ab.

Jedes Element beantwortet eine engere Frage als „Kam der Nutzer online?“. Genau diese Auflösung trennt einen abgelehnten Identitätsnachweis von gültigen Daten, die an einer Richtlinie scheitern, eine erfolgreiche Autorisierung von einem nicht unterstützten Dienst und eine abgeschlossene Methode von einem fehlenden Datenpfadschlüssel.

Quellen