Zusammenfassung

  • RFC 5421 beschreibt EAP-FAST-GTC mit Typ 6, der bereits EAP-GTC zugewiesen war, für einen anders formatierten inneren Austausch im Tunnel.
  • Die Verbote für Nutzung innen und außen sowie der Kompatibilitätshinweis des IESG machen den EAP-FAST-Kontext zu einem Teil der Methodenidentität. Das ist eine Schlussfolgerung für die Implementierung, kein Beleg für einen gemessenen Ausfall.

Ein Byte, aber keine vollständige Identität

Das Type-Feld von EAP ist ein Oktett lang und steuert dennoch den Verarbeitungsweg. RFC 3748 beschreibt Type als Kennzeichnung der Methode; EAP-Schichten verteilen Pakete anhand dieses Werts an die jeweilige Methode – vergleichbar mit einer Portnummer auf der Transportschicht. Bei Type 6 scheint die Sache damit klar: Generic Token Card.

RFC 5421 ergänzt einen Rahmen, der im einzelnen Byte nicht sichtbar ist. Das Informational Memo von 2009 dokumentiert EAP-FAST-GTC, eine innere Methode für einen einfachen Passwortaustausch. Als Zwecke nennt es unter anderem ältere Passwortdatenbanken, Passwortänderungen und Einmalpasswort-Abläufe. Aus historischen Gründen nutzt die Methode den ursprünglich EAP-GTC zugewiesenen Code. Auch das aktuelle IANA-Register führt Type 6 als „Generic Token Card“; RFC 5421 hat keine zweite globale Zuweisung geschaffen.

Der Unterschied liegt im Rahmen und im Payload-Format. EAP-FAST richtet einen TLS-Tunnel ein; in der inneren Phase werden EAP-Pakete in EAP-Payload-TLVs gekapselt. RFC 5421 weist darauf hin, dass das EAP-FAST-GTC-Format für den Tunnel bestimmt und nicht zwingend mit dem außerhalb verwendeten EAP-GTC kompatibel ist. Deshalb gelten zwei spiegelbildliche Grenzen: EAP-FAST-GTC DARF NICHT außerhalb eines EAP-FAST-Tunnels laufen, EAP-GTC DARF NICHT innerhalb davon laufen.

Diese Regeln bestimmen zugleich, was Type 6 in den jeweiligen Situationen bedeutet. Behält ein Dispatcher nur den Type-Wert und verliert, ob das Paket aus dem äußeren Austausch oder der inneren EAP-FAST-Phase stammt, geht Information verloren, die das Protokoll zur Unterscheidung der Methoden nutzt. Das ist eine Implementierungsfolge der Spezifikation, keine Behauptung, dass bestehende Systeme diesen Fehler gemacht hätten.

Der Kompatibilitätshinweis ist ausdrücklich

Der IESG-Hinweis in RFC 5421 bezeichnet die Wiederverwendung bereits zugewiesener EAP-Type-Codes als unvereinbar mit der Methodenaushandlung aus RFC 3748. Da EAP-GTC keine methodenspezifische Versionsaushandlung hat, wird Type 6 innerhalb des Tunnels als EAP-FAST-GTC verstanden. Das könne Probleme verursachen, wenn eine Implementierung zusätzlich EAP-GTC eines anderen Herstellers unterstützen muss. Derselbe Code innen und außen erfordert außerdem Sonderbehandlung. Ein eindeutiger Type-Code hätte die Schwierigkeit vermieden; für künftige Tunnelmethoden sollen zugewiesene Typen nicht mit anderer Bedeutung wiederverwendet werden.

Die Aussage darf nicht überdehnt werden: RFC 5421 belegt weder, dass jede Aushandlung scheitert, noch dass Type 6 widerrufen wurde oder ein bestimmtes aktuelles Produkt fehlerhaft ist. Dokumentiert wird ein Kompatibilitätspreis für eine kontextabhängige Bedeutung. Das Register nennt die globale Zuweisung, die Tunnelregeln begrenzen die innere Nutzung, und der IESG-Hinweis erklärt die Spannung zwischen beidem.

Als redaktionelle Perspektive hilft der Vorrang des laufenden Codes: Ein Registereintrag ist noch kein vollständiges System. Entscheidend ist auch, welche Schicht der empfangende Code erkennt und welche Methode er auswählt. Heng Lus Note 65 liefert dafür eine Linse, aber keine Evidenz zu EAP-Anforderungen oder zum Verhalten von Herstellern.

Der Schutz der Zugangsdaten ist eine andere Grenze

RFC 5421 hält außerdem fest, dass EAP-FAST-GTC Passwortinformationen als Klartextzeichenfolgen innerhalb des verschlüsselten TLS-Tunnels überträgt. Der Peer muss den Server authentisieren, bevor er Zugangsdaten offenlegt. Im Server-Unauthenticated-Provisioning-Modus, der den Server nicht authentisiert, DARF EAP-FAST-GTC nicht eingesetzt werden. Das ist eine wichtige Sicherheitsbedingung, aber eine andere Frage als der Type-Code: Verschlüsselung löst die Methodenauswahl nicht automatisch; die richtige Methode beweist wiederum nicht, dass der Server authentisiert wurde.

Für Betreiber liegt der Prüfpunkt an der Grenze: Wo entscheidet das System, ob Typ 6 gewöhnliches EAP-GTC oder EAP-FAST-GTC bedeutet? Neben Type muss die Tunnelphase berücksichtigt werden, und die wechselseitigen Verbote müssen greifen. Tests können GTC außen und FAST-GTC innen prüfen und die jeweils umgekehrte Kombination zurückweisen. Das sind hier vorgeschlagene Prüfpraktiken, keine zusätzlichen RFC-Anforderungen.

RFC 5421 hat den Status Informational. Die verfügbaren öffentlichen Quellen belegen weder heutige Verbreitung noch aktuelles Herstellerverhalten oder konkrete Vorfälle. Die belastbare Lehre ist enger: Wird ein Methodencode unter einem Tunnel wiederverwendet, wird der äußere Rahmen zu Laufzeitkontext, den ein Dispatcher nicht verwerfen sollte.

Quellen