Zusammenfassung

  • RFC 5422 rät von Netzzugang nach Server-Unauthenticated Provisioning ab; im authentisierten Modus kann die Serverrichtlinie ihn nach erfolgreicher Provisionierung erlauben.
  • Die Tunnel-PAC-Bestätigung meldet die vom Peer angegebene Verarbeitung und Speicherung; sie belegt weder Folgeauthentisierung noch Zulassung.

Ein Bootstrap endet vor der Zulassung

Ein Gerät kann ohne gemeinsamen Schlüssel, vertrauenswürdige Serverwurzel oder Protected Access Credential eintreffen. RFC 5422 beschreibt, wie EAP-FAST solche Angaben dynamisch bereitstellt. Die entscheidende Frage lautet nicht nur, ob der Austausch gelang. Sie lautet, ob er das Gerät vorbereitet oder zugleich zur Nutzung des Netzes berechtigt. Die Spezifikation hält diese Ergebnisse auseinander.

EAP-FAST verbindet eine TLS-Phase 1 mit einer inneren EAP-Phase 2. RFC 5422 unterscheidet Provisionierung mit und ohne Serverauthentisierung. Im authentisierten Modus prüft der Peer den Server im TLS-Handshake und benötigt dafür bereits Vertrauensmaterial. Der nicht authentisierte Modus beginnt dagegen mit einem anonymen Diffie–Hellman-TLS-Tunnel. Das senkt die Einstiegshürde, weist aber die Identität des Servers zunächst nicht nach.

Anonym heißt nicht authentisierungslos. Peer und Server müssen innerhalb des Tunnels ein EAP-Verfahren mit gegenseitiger Authentisierung und Schlüsselableitung abschließen. Anschließend prüft der Peer das Crypto-Binding-TLV, das den inneren Austausch an die Integrität des TLS-Tunnels bindet und einen aktiven Mittelsmann erschweren soll. Die RFC von 2009 verlangt von Implementierungen dieses Modus, EAP-FAST-MSCHAPv2 als inneres Authentisierungsverfahren zu unterstützen. Ein Erfolg der inneren Phase ohne Bindung an den äußeren Kanal wäre ein unvollständiger Befund. (RFC 5422 §§2, 3.2–3.2.3, 6.1.2; RFC 4851)

Erst nach innerer Authentisierung und erfolgreichem Crypto-Binding kann der Server einen Tunnel PAC mit PAC-Key und PAC-Opaque oder vertrauenswürdige Serverwurzeln ausliefern. Der Tunnel PAC ermöglicht einen späteren EAP-FAST-Tunnel; er ist selbst keine Berechtigung für Netzwerkressourcen.

Mit PAC-Acknowledgement meldet der Peer das Ergebnis der Verarbeitung und Speicherung eines neu provisionierten Tunnel PAC. Für andere PAC-Arten ist dieses TLV nicht vorgesehen. Der Server erhält damit die Aussage des Peers zum Speichern, aber keinen Nachweis einer späteren erfolgreichen Authentisierung, einer Freigabe durch die Zugangsrichtlinie oder erreichbarer Anwendungsdienste. (RFC 5422 §§3.2, 4.1.4, 4.2.5)

RFC 5422 formuliert die Grenze ausdrücklich: Nach Server-Unauthenticated Provisioning SOLLTE kein Netzzugang gewährt werden, weil der Austausch nur der Provisionierung dient. Die Peer-Richtlinie kann die Verbindung beenden und mit den neuen Angaben einen weiteren EAP-FAST-Austausch starten. Nach Server-Authenticated Provisioning KANN der Server den Zugang dagegen nach erfolgreicher Provisionierung erlauben. Ein allgemeiner Status „Provisionierung erfolgreich“ fasst diese Modi nicht zusammen. (RFC 5422 §3.5)

Die Wahl verteilt Aufwand und Risiko. Serverauthentisierung schützt besser vor Mittelsmännern, setzt aber vorinstalliertes Vertrauen voraus. Der anonyme Modus vereinfacht Zero-Touch-Start, erhöht laut RFC 5422 aber die Exposition passwortbasierter Phase-2-Verfahren gegenüber Offline-Wörterbuchangriffen. Das Dokument empfiehlt Begrenzungen für Onlineversuche und regt an, den Ort oder die Bedingungen des anonymen Modus einzuschränken. Das sind Aussagen eines Informational-RFC von 2009, keine heutigen Nutzungszahlen. (RFC 5422 §§6.1–6.3)

Ein belastbarer Betriebsnachweis führt Startmodus, innere gegenseitige Authentisierung und Crypto-Binding, Art und Ablaufdatum des Credentials, Tunnel-PAC-Bestätigung, spätere Authentisierung und endgültige Zugangsentscheidung getrennt. Gehören Provisionierung und Netzzulassung verschiedenen Teams, brauchen sie eine gemeinsame Sitzungskennung und einen klaren Eigentümer für fehlende Folgeaustausche. Der Erfolg der ersten Phase kann den fehlenden Schritt nicht ersetzen.

Ein erfolgreicher innerer Abschluss kann trotzdem in einer Ablehnung enden

Abschnitt 3.5 überlässt die Zugangsentscheidung auch nach erfolgreicher Provisionierung der Serverrichtlinie. Im serverauthentisierten Modus darf der Server den Zugang freigeben, nachdem er den Peer authentisiert und mit einem Tunnel PAC versorgt hat. Im nicht serverauthentisierten Modus SOLLTE am Ende kein Zugang gewährt werden, weil der Austausch ausschließlich der Provisionierung dient. Die Credential-Ausgabe erzeugt also nicht in beiden Modi dasselbe Autorisierungsergebnis.

Auch ein positiver Result TLV entscheidet nicht über den Netzzugang. Die innere EAP-Methode kann erfolgreich abgeschlossen sein, während der Server seine Zugangsrichtlinie noch nicht als erfüllt ansieht und mit EAP Failure beendet. Ist der Austausch nicht zur Zugangsgewährung bestimmt, darf der Server laut RFC 5422 weder Zugang gewähren noch Sitzungsschlüssel an den Network Access Server weitergeben. Ein Dashboard, das nur den Erfolg der inneren Methode zählt, kann einen grünen Status anzeigen, obwohl das Netz die Zulassung korrekt verweigert hat.

Der Nachweis muss bis zum endgültigen EAP-Ergebnis und einer möglichen Schlüsselübergabe reichen. (RFC 5422 §3.5; RFC 4851 §4.2.2)

Die Bestätigung deckt nur einen Abschnitt im Credential-Lebenszyklus ab

Ein Tunnel PAC besteht aus mehreren Bestandteilen. Der PAC-Key ist ein 32 Oktett langes Geheimnis für den Phase-1-Tunnel. Das serverspezifische PAC-Opaque wird dem ausstellenden EAP-Server später erneut vorgelegt. PAC-Info kann die ausstellende Instanz und eine Laufzeit enthalten. RFC 4851 verlangt den Schutz des PAC-Key; RFC 5422 weist Peer und Server eigene Pflichten zur sicheren Speicherung zu. Mit der Ausgabe beginnen somit weitere Aufgaben: Schutz, Ablauf und Erneuerung brauchen einen Verantwortlichen.

Der PAC-Acknowledgement hat einen engen Zweck. Der Peer sendet ihn für einen neu provisionierten Tunnel PAC und meldet den Erfolg oder Misserfolg von Verarbeitung und Speicherung. Der Erfolgswert dokumentiert, was der Peer zu diesem Zeitpunkt zurückmeldet. Er beweist weder, dass sich später ein Tunnel aufbauen lässt, noch dass das Geheimnis weiter geschützt bleibt oder Netzzugang freigegeben wird. Erst ein späterer EAP-FAST-Austausch erprobt das Credential im neuen Authentisierungskontext; auch das ist noch kein Nachweis erreichbarer Anwendungsdienste. (RFC 5422 §§4.2.2–4.2.5, 6.8; RFC 4851 §3.2.2)

Eine Ablehnung kann die Verbindung unterbrechen

Die Trennung hat einen Verfügbarkeitsaufwand. RFC 5422 weist darauf hin, dass EAP Failure nach einer Zugangsverweigerung bei 802.11-Geräten eine vollständige WLAN-Verbindungstrennung auslösen kann. Peer oder Server können eine TLS-Neuaushandlung versuchen, damit die neuen Angaben ohne kompletten Neustart in eine spätere Authentisierung übergehen; beide Seiten dürfen den Wunsch jedoch ablehnen. Die normale Zugangsrichtlinie gilt erst nach erfolgreicher Folgeauthentisierung. Betreiber sollten daher Rückkehr, Ablehnung sowie Neustart oder TLS-Neuaushandlung messen.

Sonst sieht eine vorgesehene Verweigerung wie ein Provisionierungsfehler aus, oder eine Erfolgszahl verschweigt Geräte, die nie zugelassen wurden. (RFC 5422 §3.5)

Quellen