Zusammenfassung

  • RFC 5113 trennte Anschlussentdeckung, Identitätswahl, AAA-Routing, Nutzdatenpfad und Servicefähigkeit.
  • Realm-Hinweise waren begrenzte Fehlerbehebung nach einem Routingfehler, keine vollständige oder dynamische Routentabelle.
  • Die Auswahl geschah vor der Authentisierung. Anzeigen mussten deshalb als Hinweise gelten, später soweit möglich bestätigt und durch eine vorab festgelegte Sicherheitspolitik begrenzt werden.

Ein NAS sendet EAP-Response/Identity-Pakete, um vom AAA-Kern Hinweise auf erreichbare Realms zu bekommen. Was wie automatische Aktualisierung aussieht, ist tatsächlich ein Probeverkehr gegen die Produktionssteuerung.

Ist ein AAA-Server bereits überlastet und verwirft Pakete, folgen Retransmissions. Die Last steigt genau dort, wo der NAS mehr Klarheit sucht. Die Antwort bleibt dennoch unvollständig, weil Paketgröße und Vertraulichkeit eine vollständige Tabelle verhindern können.

Fehlerhilfe war keine Routingebene

RFC 4284 konnte nach einem fehlgeschlagenen Realm-Routing Alternativen in einer EAP-Identitätsanfrage nennen. RFC 5113 ordnete diesen Mechanismus als Recovery ein. Ein Peer erhält einen Anhaltspunkt für eine andere Identity, nicht das gesamte aktuelle Netz möglicher Beziehungen.

Eine Liste kann Einträge aus Platzgründen weglassen. Betreiber können Realm-Beziehungen als vertraulich behandeln. Ein NAS, das eine solche Nachricht mitliest, darf deshalb keine Vollständigkeit unterstellen.

Die Grenze ist operativ wichtig. Ein Recovery-Hinweis darf scheitern und zu einem begrenzten zweiten Versuch führen. Eine vermeintliche Routingtabelle steuert dauerhaft und lautlos viele Entscheidungen.

Fate Sharing statt manueller Kopien

Wenn jeder NAS eine manuell gepflegte Realm-Tabelle hält, driftet die Anzeige vom Kernrouting. Entfernte Beziehungen bleiben am Rand sichtbar. Neue Beziehungen fehlen. Der Client erfährt den Unterschied erst, nachdem er Anschluss, Netz und NAI gewählt hat.

Der Core-AAA-Proxy, der den nächsten Request tatsächlich routen muss, ist der bessere Ursprung des Hinweises. Behauptung und Handlung liegen dann in derselben Komponente. Dieses Fate Sharing garantiert nicht die optimale Route, reduziert aber widersprüchliche Zuständigkeit.

Zentralisierung allein reicht nicht. Der Hinweis braucht Alter, Ursache und begrenzten Geltungsbereich. Sonst wird auch die zentrale Aussage zur dauerhaften Wahrheit erklärt.

Die fünf getrennten Entscheidungen

Der sichtbare Point of Attachment zeigt eine lokale Verbindungsmöglichkeit. Höhere Dienste, Roamingbeziehungen, Internetrestriktionen und Preis können fehlen.

NAI und Credential bestimmen die präsentierte Identität. Der Realm beeinflusst das Routing zum Home-Server.

AAA-Routing entscheidet, welche Proxies und Beziehungen den Kontrollaustausch tragen.

Payload-Routing kann anschließend einen anderen Tunnel benutzen.

Network Capability Discovery betrifft das tatsächliche Ziel: Service, Sicherheit, Qualität, Erreichbarkeit und Charging.

Ein Authentication Success kann diese Ebenen nicht rückwirkend vereinigen.

Credential-Wahl war Route-Wahl

RFC 5113 fasste Credential Selection und AAA Routing als gemeinsame Identity Selection auf. Wer eine andere Identity wählt, wählt möglicherweise einen anderen Realm und damit eine andere Infrastruktur.

Mehrere Roamingpfade können denselben Account akzeptieren. Direkte und indirekte Beziehungen können unterschiedliche Dienste und Preise liefern. Ein grünes EAP-Ergebnis beantwortet nicht, welcher wirtschaftliche Pfad benutzt wurde.

Die Telemetrie muss NAI, Proxyfolge, Relation und späteren Datentunnel zusammenhalten. Sonst wird ein Routingfehler als falsches Passwort klassifiziert oder eine unerwünschte Route als erfolgreicher Nutzerzugang gefeiert.

Auswahl vor Vertrauen

Um Verzögerung zu vermeiden, sollen Informationen vor der Authentisierung verfügbar sein. Zu diesem Zeitpunkt existieren die daraus abgeleiteten dynamischen Schlüssel noch nicht.

Vorinstallierte Schlüssel oder Signaturen können Anzeigen schützen, erzeugen jedoch Provisionierung, Ablauf und Widerruf. Späteres Channel Binding kann bestimmte Werte bestätigen. Nicht enthaltene Service-, Preis- oder Routingaussagen bleiben offen.

Ein Angreifer kann eine schwächere Option bewerben. Wenn die spätere Methode den ursprünglichen Claim nicht bindet, entsteht Bidding Down. Der Client muss daher eine Mindestpolitik vor der Discovery besitzen und widersprechende Anzeigen ignorieren können.

Privatsphäre und Tabellenumfang

Der Peer könnte alle unterstützten Realms offenlegen, damit der Authenticator auswählt. Vor der Authentisierung wäre diese Liste Klartext und verriete mögliche institutionelle Bindungen.

Selektive Offenlegung schützt Privatsphäre, erhöht aber mitunter die Zahl der Versuche. Dieser Trade-off verlangt ein Budget. Jede zusätzliche Identity muss begründet und protokolliert werden.

Auch Betreiber wollen womöglich ihre Routingbeziehungen nicht vollständig veröffentlichen. Eine Architektur, die für Korrektheit vollständige Offenlegung benötigt, baut daher auf einer Information, die beide Seiten vermeiden möchten.

Service und Datenpfad

Der Kontrollpfad zum Home-AAA und der Payload-Tunnel sind nicht identisch. Nach erfolgreicher Authentisierung kann der gewünschte Dienst fehlen oder die Abrechnung einer anderen Relation folgen.

User Preference, Operator Preference und Application Requirement können verschiedene Netze bevorzugen. Die Reihenfolge in einer lokalen Tabelle ist keine dokumentierte Entscheidung zwischen diesen Zielen.

Ein auditierbares System speichert Auswahlziel, angenommene Claims, bestätigte Claims, realen Tunnel, Serviceergebnis und Charging. Ohne Ziel bleibt „beste Auswahl“ bedeutungslos.

Evidenzleiter

  • sichtbarer Access Point beweist keinen gewünschten Service;
  • advertised Realm beweist keine aktuelle Route;
  • Realm Hint beweist keine vollständige Tabelle;
  • AAA-Erreichbarkeit beweist keine akzeptierte Identity;
  • Authentisierung beweist keinen Payload-Pfad;
  • funktionierender Payload beweist keinen Preis;
  • eine Session beweist keine optimale Netzwahl.

RFC 5113 schützt vor einem häufigen Automatisierungsfehler: Eine Hilfsnachricht wird zum Steuerungsmodell erhoben, weil sie leicht abzufragen ist.

Quellen