Zusammenfassung

  • RFC 5281 trennt bei EAP-TTLSv0 den TLS-Handshake von der geschützten Datenphase. Ohne Clientzertifikat authentisiert Phase 1 den TTLS-Server; die wirkliche Kennung und der Nachweis des Teilnehmers erscheinen erst in Phase 2.
  • Ein belastbarer Zugangsbeleg verknüpft äußere Routing-Identität, Zertifikatsprüfung, inneres Verfahren und Identität, AAA-Entscheid, Autorisierung, Schlüsselübergabe, Umsetzung am Access Point und beobachteten Verkehr. Kein früher Erfolg beweist automatisch den späteren.

Finished bedeutet: Die eigentliche Frage kann geschützt beginnen

Phase 1 von EAP-TTLSv0 ist der TLS-Handshake. Der TTLS-Server legt sein Zertifikat vor, der Client prüft Vertrauenskette, erwarteten Namen und Richtlinie. Ein Clientzertifikat ist optional. Mit ChangeCipherSpec und Finished wird die geschützte Record-Schicht nutzbar.

Damit ist eine eng begrenzte Aussage belegt: Der Client besitzt einen verschlüsselten Kanal zu dem TTLS-Endpunkt, den er als Server akzeptiert hat. Im üblichen Zweig ohne Clientzertifikat ist über den Teilnehmer noch nicht entschieden. Phase 2 trägt AVPs mit echtem Benutzernamen, Passwortnachweis, innerem EAP, Integritäts-, Konfigurations- oder Provisionierungsdaten.

„TLS steht“ ist daher kein Synonym für „Teilnehmer authentisiert“. Es belegt weder eine Annahme durch das Heim-AAA noch eine aktuelle Autorisierung, die Installation am Access Point oder erfolgreichen Nutzverkehr. Gerade die Zweiteilung des Verfahrens hält diese Aussagen auseinander.

RFC 5281 ist Informational und beschreibt damalige Betriebspraxis. Seine historische Zulassung von TLS 1.0 und 1.1 ist keine aktuelle Empfehlung: RFC 8996 verbietet beide Versionen, RFC 9427 aktualisiert EAP-TTLS für TLS 1.3 bei Schlüsselableitung und Ergebnisbehandlung. Modernere Kryptographie hebt die Identitäts- und Durchsetzungsgrenzen nicht auf.

Die erste Kennung kann nur eine Routingangabe sein

Noch vor dem Tunnel fragt der Access Point häufig nach EAP-Response/Identity. Diese Antwort liegt außerhalb des geschützten Kanals. Zum Schutz der Privatsphäre darf der Client den echten Benutzernamen weglassen, einen anonymen Platzhalter senden und lediglich den Realm behalten, der die Anfrage zum richtigen Anbieter lenkt.

Die äußere Kennung beantwortet somit „Wohin gehört dieser Dialog?“, nicht „Wer beantragt Zugang?“. Die innere Identität reist später im TLS-Tunnel und wird von der zuständigen AAA-Autorität gegen das gewählte Verfahren geprüft.

Ein einziges Logfeld namens identity zerstört diese Unterscheidung. Überschreibt die innere Kennung die äußere, verschwindet der Routingpfad. Bleibt nur der anonyme äußere Wert, wird der AAA-Entscheid einem Platzhalter zugeschrieben. Beide Werte brauchen eigene Rollen, Beobachter, Zeitpunkte und Transaktionsbezüge.

Der Tunnel endet am TTLS-Terminator

TLS schützt die inneren AVPs bis zum TTLS-Server. Dort werden sie entschlüsselt und passende Authentisierungsdaten über RADIUS, Diameter oder einen anderen AAA-Carrier an AAA/H weitergegeben. TTLS-Terminator und Heim-AAA können zusammenfallen, müssen es aber nicht; auch Proxys können dazwischenliegen.

Der äußere Tunnel ist folglich keine durchgehende Verschlüsselung vom Client bis zu jeder Backend-Autorität. Die hintere Strecke benötigt eigene Nachweise für Gegenstellenidentität, Vertraulichkeit, Integrität und Berechtigung. Ein grünes TLS-Symbol sagt über diese Strecke nichts aus.

Der Terminator ist außerdem keine neutrale Leitung. Er sieht die geschützten Anmeldedaten, übersetzt AVP-Kontexte und wählt aus, was weitergereicht wird. RFC 5281 warnt, dass derselbe AVP-Code in EAP-TTLS und im Backend nicht zwingend dieselbe Bedeutung trägt. Ein Attribut darf nur kopiert werden, wenn beide Semantiken verstanden sind. Gleiche Syntax ist kein Beleg für gleiche Absicht.

Authentisierung kann aus mehreren Urteilen bestehen

AAA/H kann eine Challenge, eine Annahme oder eine Ablehnung liefern. Eine Challenge kehrt über den TTLS-Server in den geschützten Kanal zurück. Erst nach allen von der Richtlinie verlangten Wechseln entsteht ein Gesamtergebnis, das auf den äußeren EAP-Ablauf abgebildet wird.

Auch mehrere innere Verfahren sind möglich, etwa Passwort und anschließend Token. Ob alle erfolgreich sein müssen oder eines genügt, ist eine Richtlinienfrage. Die Meldung „inneres Verfahren erfolgreich“ bleibt unvollständig, solange Reihenfolge, Einzelergebnisse und die auswertende Richtlinienversion fehlen.

Es gibt berechtigte Zweige ohne Phase 2. Ein Clientzertifikat kann bereits in Phase 1 genügen, oder eine wiederaufgenommene Sitzung kann eine frühere erfolgreiche Authentisierung übernehmen. Das Fehlen eines inneren Transkripts ist deshalb für sich kein Fehler. Der gewählte Zweig und die geerbte Identität samt Autorisierung müssen aber feststehen.

Gefährlich ist der umgekehrte Fall: Eine Sitzung schließt TLS erfolgreich ab, scheitert innen und wird dennoch als wiederaufnehmbar gespeichert. RFC 5281 nennt die Konsequenz katastrophal. Wiederaufnahmeberechtigung muss von erfolgreicher Teilnehmerauthentisierung stammen, nicht vom bloßen Handshake.

Ableitbare Schlüssel sind noch keine Nutzungsbefugnis

Aus TLS-Geheimnis und Zufallswerten lassen sich MSK und EMSK ableiten. Nach erfolgreicher Authentisierung werden Schlüsselmaterial und Autorisierungsdaten über den AAA-Pfad zum Access Point übermittelt.

Das sind zwei getrennte Tatsachen. Software kann mögliche Bytes berechnen, bevor eine Richtlinie ihre Verwendung freigibt. Ein Schlüssel kann der falschen Sitzung zugeordnet werden, mit einer veralteten Autorisierung eintreffen, nicht installiert werden oder einen Link schützen, der weiterhin keinen brauchbaren Dienst liefert.

Die richtige Frage lautet daher nicht nur: „Wurde ein Schlüssel erzeugt?“ Ein Beleg muss zeigen, aus welchem Transkript und welchen Identitäten er stammt, welcher Entscheid die Ausgabe freigab, welche Access-Point-Sitzung ihn übernahm, welche Richtlinie ihn begleitete und welcher Verkehr die beabsichtigte Wirkung zeigte.

Erfolg erreicht Client und Vollstrecker auf verschiedenen Wegen

Akzeptiert AAA/H den Teilnehmer, sieht der Client üblicherweise EAP-Success. Der Access Point erhält über den AAA-Carrier Annahme, Schlüssel und Parameter für Filter, logisches Netz, Zeit oder Bandbreite. Beide Ausgaben gehen auf denselben Entscheid zurück, besitzen aber verschiedene Empfänger und Transportwege.

EAP-Success beim Client beweist nicht, dass der Access Point dieselbe Richtlinie umgesetzt hat. Ein eingegangenes Access-Accept beweist nicht, dass VLAN oder Filter tatsächlich installiert wurden. Selbst aktive Linkverschlüsselung belegt weder Adressvergabe noch Routing, DNS oder Erreichbarkeit einer Anwendung.

Die Aussage „Zugang wiederhergestellt“ braucht deshalb eine Rücklesung am Durchsetzungspunkt und beobachteten Verkehr; nennt die Aussage einen Dienst, gehört dessen Ergebnis ebenfalls in den Beleg. Die Identitätsautorität kann ihren Entscheid bezeugen, nicht alle nachgelagerten Wirkungen, die sie nie beobachtet hat.

Zwei erfolgreiche Schichten sind noch nicht gebunden

RFC 5281 nennt eine bekannte Grenze des Basismodells: EAP-TTLSv0 besitzt keine kryptographische Bindung zwischen äußerer TLS- und innerer Authentisierung. Ein Nachweis, der innerhalb und außerhalb des Tunnels wiederverwendbar ist, kann in einen anderen Kontext weitergeleitet werden. Das Dokument rät von solcher Wiederverwendung ab und verweist auf Erweiterungen, die beide Schichten binden.

Das macht nicht jede EAP-TTLS-Sitzung unrechtmäßig. Es zeigt aber, dass „beide Schritte waren erfolgreich“ schwächer ist als „beide Schritte gehören nachweislich zu demselben authentisierten Kontext“. Garantien späterer Tunnelmethoden dürfen nicht stillschweigend dem Basismodell zugerechnet werden.

Der Zugangsbeleg folgt der Reihenfolge der Grenzen

Für einen folgenreichen Zugangsentscheid sind mindestens festzuhalten:

  • Identitäten von Client, Access Point, TTLS-Server und AAA/H;
  • äußere Klartextkennung, Routing-Realm und Proxypfad;
  • Serverzertifikatskette, erwartete Namensregel und Prüfergebnis;
  • TLS-Version, Cipher Suite, Transkript und Abschluss von Phase 1;
  • Clientzertifikat und dessen tatsächliche Authentisierungsrolle;
  • neue oder wiederaufgenommene Sitzung samt geerbter Authentisierung und Autorisierung;
  • innere Identität, Verfahrensfolge, Challenges und Einzelergebnisse;
  • TTLS–AAA-Transaktion und Schutz des Carrier-Pfads;
  • Annahme oder Ablehnung, Richtliniengeneration und zurückgegebene Autorisierung;
  • vom Client beobachtetes EAP-Success oder EAP-Failure;
  • Übergabe des MSK und Bindung an die richtige Access-Point-Sitzung;
  • tatsächlich installierte Filter, Netz-, Zeit- und Bandbreitenvorgaben;
  • Linkschutz und beobachteter bidirektionaler Verkehr; sowie
  • das Anwendungsergebnis, das die Betriebsaussage verlangt.

Der Beleg muss an jeder Grenze enden dürfen. Ein sicherer Tunnel kann einen abgelehnten Teilnehmer enthalten. Ein angenommener Teilnehmer kann an der Durchsetzung scheitern. Ein geschützter Link kann nutzlos bleiben. Diese Trennung ist keine Pedanterie, sondern verhindert, dass der erste grüne Zustand den letzten Erfolg vortäuscht.

Sources