Zusammenfassung

  • RFC 2989 bewertete Fähigkeiten von AAA-Vorschlägen; eine Pflichtfähigkeit musste nicht in jedem Austausch aktiv sein.
  • Getrennte Spalten für NASREQ, ROAMOPS und Mobile IP bewahrten verschiedene Anforderungen statt einer universellen Betriebspolitik.
  • Transportbestätigung, syntaktische und semantische Annahme, Abrechnungsverantwortung, Autorisierungswirkung und Dienst waren getrennte Belege.

Was die Matrix bewertete

RFC 2989 definierte kein neues AAA-Drahtprotokoll. Der Informational RFC fasste Anforderungen aus NASREQ, ROAMOPS, MOBILEIP und TIA 45.6 zusammen, um Kandidaten vergleichen zu können.

Allgemeine, Authentifizierungs-, Autorisierungs-, Accounting- und Mobile-IP-Tabellen behielten die Quellspalten. M, S, O, N und B standen für MUST, SHOULD, MAY, MUST NOT und SHOULD NOT. Die gemeinsame Form schuf Vergleichbarkeit; die getrennten Spalten verhinderten eine erfundene Einheitsanforderung.

Abschnitt 1.1 begrenzte die Aussage. Die Normsprache bezog sich auf Protokollfähigkeiten. Ein Vorschlag, der für eine implementierte Fähigkeit ein MUST verletzte, war nicht konform. Wer Pflicht-, aber nicht alle Empfehlungspunkte erfüllte, war bedingt konform; mit allen Empfehlungen unbedingt konform.

Das waren Urteile über einen Vorschlag, nicht über eine Installation.

Das Vertraulichkeitsbeispiel machte es unmissverständlich. Unterstützung bedeutete nicht Verschlüsselung jedes Verkehrs. Ein konkreter Austausch brauchte zusätzliche Belege: Version, Profil, Konfiguration, Schlüssel, Gegenstelle, Aushandlung, Schutzumfang und Prüfergebnis.

Ein MUST ist keine Telemetrie

RFC 2119 stärkt eine Pflicht innerhalb ihres festgelegten Gegenstands. Es verwandelt eine Entwurfsanforderung nicht in einen Laufzeitbericht.

Skalierbarkeit war in drei Bereichen Pflicht. Failover war bei NASREQ und Mobile IP stark markiert. IPv4 war allgemein erforderlich; IPv6, Zertifikatstransport und Auditierbarkeit hatten unterschiedliche Gewichte. Leer bedeutete nicht verboten. M bedeutete nicht, dass jede Nachricht die Funktion auslöste.

Die spätere Überdehnung ist bequem: Protokollkonformität wird Produktgarantie, Produktgarantie wird vermutete Konfiguration, eine Verbindung wird zum gelieferten Dienst. Jede Stufe braucht eine neue Beobachtung.

Eine minimale gemeinsame Spezifikation koordiniert Vergleich und Interoperabilität, ohne alle künftigen lokalen Entscheidungen zu besitzen.

Hop-Schutz und Objektschutz

Transportsicherheit galt hopweise. Benachbarte AAA-Partner konnten Authentifizierung, Integrität und Vertraulichkeit herstellen. Sobald die empfangende AAA-Entität die Nachricht verarbeitete, endete dieser Schutz. Der nächste Hop brauchte eine neue Beziehung.

Objektvertraulichkeit konnte Attribute für das Endziel schützen, obwohl Proxys oder Broker dazwischen lagen. Objektauthentifizierung und -integrität sollten die Kette überdauern; geschützte Daten durften Zwischenserver nicht ändern.

Unterstützung beider Modelle bewies nicht ihre Laufzeitkomposition. Funktionen konnten deaktiviert, wichtige Felder ungeschützt, Schlüssel veraltet oder Prüfungen fehlgeschlagen sein. Konfiguration und Trace mussten den tatsächlichen Weg zeigen.

Zugestellt, aber noch nicht verstanden

Zuverlässiger AAA-Transport umfasste hopweise Wiederholung und Serverwechsel, Kontrolle durch die AAA-Anwendung, rechtzeitige Antworten und Bestätigungen.

RFC 2989 nannte eine Transportbestätigung für erfolgreiche Zustellung und trennte sie ausdrücklich von syntaktischer oder semantischer Bewertung.

Ein Server konnte den Empfang bestätigen und Attribute später ablehnen. Ein Proxy konnte einen Hop abschließen und am nächsten scheitern. Ein Ersatzserver konnte erreichbar sein, aber aktuellen Sitzungszustand vermissen. Eine schnelle Antwort konnte eine Ablehnung sein.

Der Betriebsnachweis muss deshalb Versuch, Hop, Wiederholung, Failover-Ziel, Transportbeleg, Parsergebnis, Entscheidung und NAS-Aktion getrennt halten.

Die Trennung minderte Transportzuverlässigkeit nicht. Sie entzog ihr nur eine Aussage, die sie nicht beobachtet hatte.

Accounting nahm Verantwortung an

Garantierte Accounting-Zustellung nutzte eine andere Bestätigung. Sie lag auf Anwendungsebene und wurde gesendet, wenn der empfangende Server Verantwortung für die Nachrichtendaten übernehmen wollte.

Das war stärker als Ankunft, aber kein Beweis für dauerhafte Speicherung, Replikation, Abgleich, Bewertung, Rechnung oder Zahlung. RFC 2989 unterschied Accounting als Sammlung von Nutzungsdaten vom Billing als Vorbereitung einer Rechnung.

Dynamische Neuautorisierung konnte mehrere Datensätze pro Sitzung erzeugen. Verantwortungsannahme schloss einen Abschnitt, nicht die ganze Kette.

Auditierbar heißt nicht richtig

Ein auditierbarer Prozess sollte eindeutig zeigen, welche Aktionen an AAA-Paketen auf dem Weg zwischen Home-Server und Netzgerät ausgeführt wurden.

Ein lokaler Proxy konnte Richtlinien durchsetzen. Ein transparenter Proxy sollte nichts hinzufügen, löschen oder ändern. Ein Proxy-Broker blieb im Pfad; ein Routing-Broker konnte Informationen für direkten Kontakt liefern.

Ein Protokoll zeigte die Veränderung. Es bewies nicht deren Erlaubnis, die richtige Identität, die Ausführung durch das NAS oder nutzbaren Dienst. Auditierbarkeit bezeugte Verwahrung und Mutation, nicht universelle Korrektheit.

Drei A, getrennte Autorität

Authentifizierung prüfte eine behauptete Identität. Autorisierung entschied ein Recht. Accounting sammelte Nutzung. Der RFC verlangte sogar Autorisierung ohne erneute Benutzer-Credentials: Identifikation oder Assertion konnten genügen. Das machte die Assertion nicht selbstbeweisend; ihr Nachweis konnte aus einer anderen Beziehung stammen.

Ablehnung, Zugriffsregeln, Neuautorisierung, Zustandsabgleich und Trennung waren Steuerfähigkeiten. Keine bescheinigte allein den Netz- oder Diensterfolg.

Die bleibende Disziplin

Fähigkeit war nicht Aktivierung. Zustellung war nicht Interpretation. Verwahrung war nicht Rechnung. Audit war nicht Richtigkeit. Autorisierung war nicht gelieferter Zugang.

Lu Hengs Realitätsebenen ordnen Anforderung, RFC, Fähigkeit, Implementierung, Konfiguration, Nachricht, Zwischenhandlung, Entscheidung, Geräteeffekt und Ergebnis. Eine wahre Ebene darf nicht für spätere sprechen.

Laufender Code muss zeigen, welcher Mechanismus gewählt, wo bestätigt, welche Richtlinie angewandt, welcher Zustand geändert und welches Ergebnis beobachtet wurde.

Die Liste bewertete den Kandidaten. Das Netz schuldete weiterhin Belege.

Quellen