Zusammenfassung

  • RFC 3182 legte AUTH_DATA in POLICY_DATA ab. Policy Locator, Berechtigungsnachweis, Signatur und Fehlerobjekt hatten getrennte Aufgaben; keines davon vergab allein Ressourcen.
  • Die Identitätskette konnte sich unterwegs verändern. Im Unicast blieb ein Benutzer-Locator erhalten, während der aktuelle Knoten neue Credentials stellte. Im Multicast durfte der PDP auswählen, welche Anwendungsidentität übrig blieb.
  • Ein authentisierter Principal war noch nicht autorisiert. PDP-Entscheidung, PEP-Durchsetzung, Kapazität, RSVP-Zustand, Paketbehandlung und Anwendungsergebnis brauchten eigene Belege.

Zwei Fragen kamen im selben Signal an

RSVP unterschied, ob eine angeforderte Ressource verfügbar war und ob der Anfordernde sie benutzen durfte. RFC 2205 nannte das admission control und policy control. Beide Antworten mussten positiv sein. RSVP transportierte Policy-Daten, verstand sie aber nicht als fertige Berechtigung.

RFC 3182 erschien im Oktober 2001 als Proposed Standard und strukturierte Identitätsmaterial für die zweite Entscheidung. AUTH_USER stand für Benutzer, AUTH_APP für Anwendungen. POLICY_LOCATOR wies auf eine Policy. CREDENTIAL konnte Textkennung, Kerberos-Ticket oder Zertifikat enthalten. Eine Signatur schützte vorausgehende Attribute; ein Fehlerobjekt benannte die Ablehnung.

Das Dokument ersetzte RFC 2752, weil eine P-Type-Zuweisung und die Größe eines Fehlerfelds korrigiert werden mussten. Das waren keine zwei nachgewiesenen Deployment-Generationen. Auch der Datatracker-Zeitstempel von 2026 bezeichnet keine neue Protokollfassung, sondern unter anderem die Pflege eines Eintrags mit verifiziertem Erratum.

Erratum 2958 berichtigt den Kerberos-Ablauf in Abschnitt 6.3. Der Server extrahiert den Sitzungsschlüssel aus dem Ticket und authentisiert damit den Benutzer; er schickt das Ticket nicht an das KDC, um den Schlüssel abzurufen. Eine historische Darstellung muss der Korrektur folgen.

Der Locator war eine Adresse zum Regelwerk

RFC 2753 trennte den Policy Decision Point vom Policy Enforcement Point. Der PDP konnte Verzeichnisse, Authentisierung, Abrechnung, Gruppen, Zeit und lokale Konfiguration heranziehen. Der PEP setzte die Antwort am Knoten um. Selbst nach einer positiven Policy-Entscheidung konnte die Ressourcenkontrolle wegen fehlender Kapazität scheitern.

Ein Distinguished Name war daher keine Vollmacht. Ein Zertifikat war keine Bandbreite. Der Locator sagte, wo eine Regel zu finden war; das Credential lieferte Prüfmaterial; die Signatur band Bytes an eine Schlüsseloperation. Erst eine zuständige Instanz konnte den geprüften Principal einer aktuellen Policy zuordnen.

Die vollständige Belegkette lautete: behauptete Identität, Credential-Typ, Validierung, authentisierter Principal, Schlüssel- oder Realm-Geltung, Locator und Policy-Version, PDP-Entscheidung, PEP-Durchsetzung, Kapazität, RSVP-Zustand, Pakete und Anwendung. Ein gemeinsames Erfolgsfeld würde diese Zuständigkeiten auslöschen.

Text, Ticket und Zertifikat hatten verschiedene Beweiskraft

Die einfache Variante trug eine ASCII- oder Unicode-Kennung. Für Anwendungen nannte der RFC einen Dateinamen wie vic.exe. Der Text erklärte selbst, dass diese Form kein sicher authentisierbares Credential enthalte. Ein Dateiname beweist weder Binärinhalt noch Herausgeber, Prozessinhaber oder Integrität.

Kerberos verlangte ein Ticket für den nächsten RSVP-Knoten oder dessen PDP und eine kompatible Vertrauensinfrastruktur. Das Ticket konnte einen Principal im betreffenden Realm authentisieren. Es verlieh kein universelles Recht in nachfolgenden Domänen.

Die Public-Key-Variante brachte Zertifikat und Signatur mit. Sie setzte geschützten privaten Schlüssel, akzeptierte CA und Zertifikatsprüfung voraus. Auch ein gültiges Ergebnis entschied nicht über Widerruf, organisatorisches Mandat, lokale Ressourcenpolicy oder den tatsächlich sendenden Prozess.

RFC 4230 beschrieb später den Rechen- und Bandbreitenaufwand, zusätzliche Widerrufsmechanismen, unvollständige Identitätsvertraulichkeit bei Kerberos und den Abstand zwischen Authentisierung und Autorisierung. Ein stärkeres Credential stärkte einen Beleg, nicht die gesamte Kette.

Die Stimme wechselte entlang des Pfads

Für Unicast-Benutzerpolicy wurde der Locator des vorherigen Hops kopiert, während die Credentials die Identität des aktuellen Netzknotens bezeichneten. Gesuchtes Subjekt und aktuell beglaubigender Sprecher konnten auseinanderfallen.

Im Multicast repräsentierten Locator und Benutzer-Credential den aktuellen Knoten. Die Anwendungsidentität folgte einer anderen Regel: Im Unicast wurde sie kopiert; im Multicast konnte sie das erste Element in der Nachricht oder eines vom PDP ausgewählte sein.

Der verbleibende Wert war kein Teilnehmerverzeichnis. „Erstes Element“ ist eine Ordnungsregel, „vom PDP gewählt“ eine Policy-Entscheidung. Beides schafft keine kollektive Vertretung.

Mehrere AUTH_DATA-Elemente waren möglich, und policy-fähige Knoten konnten Informationen ersetzen. Deshalb muss ein Audit Eingang, Ausgang, Akteur, Vertrauensdomäne, Security Association und Grund speichern. Nur den letzten Namen aufzubewahren, zerstört die Chain of Custody.

Ein Knoten konnte weiterleiten, ohne zu urteilen

Nicht jeder RSVP-Knoten musste Policy verstehen. RFC 2753 erlaubte Durchsetzung an ausgewählten Grenzen. RFC 3182 ließ einen policy-unaware Router Policy-Objekte ignorieren und RSVP weiterverarbeiten.

Das ermöglichte schrittweise Einführung, begrenzte aber die Aussage des Durchgangs. Er zeigte nicht, dass Benutzer, Zertifikat oder Berechtigung geprüft worden waren. An einer fähigen Grenze fragte der PEP den PDP; eine negative Antwort lehnte ab, eine positive ließ den normalen RSVP-Ablauf lediglich fortfahren. Spätere Knoten konnten wegen Kapazität, anderer Regel oder Installationsfehler scheitern.

Objekt empfangen, Credential validiert, Policy genehmigt, Zustand installiert und Dienst beobachtet waren verschiedene Zustände. Das Schweigen eines unwissenden Knotens war keine Genehmigung.

Fehlercodes begrenzten die Diagnose

Vorgesehen waren nicht unterstützter Credential-Typ, unzureichende Privilegien, abgelaufenes Credential und geänderte Identität. Konnte der PDP AUTH_DATA nicht verifizieren, musste er einen Policy-Control-Fehler zurückgeben und sollte Details beifügen.

Diese Codes trennten Authentisierung von Privileg und Kapazität. Doch EXPIRED_CREDENTIAL bewies keine vollständige Zustandslöschung, IDENTITY_CHANGED keine Benachrichtigung der Anwendung und ein Fehler eines Multicast-Zweigs kein identisches Ergebnis aller Zweige.

Das heutige IANA-Register führt die Klasse POLICY_DATA und Policy-Control-Fehler. Nummernkoordination ist kein Nachweis für Implementation, Nutzung jedes Subtyps oder eine konkrete Routerentscheidung.

Integrität schützte Bytes, nicht Legitimität

RFC 3182 empfahl Integrität für POLICY_DATA, wenn die ganze RSVP-Nachricht nicht geschützt war. Innerhalb einer Security Association ließen sich Änderung und Replay erkennen.

RFC 4230 unterschied später den Schutz der äußeren RSVP-Nachricht vom inneren Policy-Container. Policy-Knoten konnten Daten absichtlich ändern, Benutzerinformationen nach dem ersten Hop preisgeben, und allgemeine Vertraulichkeit zwischen Routern fehlte.

Ein Audit fragt daher: Sind die Bytes intakt? Welchen Akteur authentisierte Schlüssel oder Ticket? Hatte dieser Akteur ein aktuelles Mandat? Kryptografie unterstützt die ersten beiden Fragen, beantwortet die dritte nicht.

RFC 2753 erwartete an Providergrenzen Umschreiben nach bilateralen Vereinbarungen. RFC 4230 stellte für Roaming fehlende standardisierte Autorisierungsdaten und kein allgemein vereinbartes Verfahren für QoS-Reservierungen fest. Identität konnte reisen; Autorität blieb lokal.

Eine belastbare Akte bewahrte auch die Verlierer

Zuerst werden behauptete Identität und Roh-Element gespeichert, dann Credential-Typ, Prüfer, Principal, Realm oder Zertifikatskette und Integritätsumfang. Danach folgen Locator, Policy-Version, PDP-Entscheidung, PEP-Ausführung, Kapazität und RSVP-Zustand. Paket- und Anwendungsbeobachtung bleiben getrennt.

Im Multicast sind alle Eingangsidentitäten, ihre Reihenfolge, der Auswahlakteur und die verworfenen Elemente zu bewahren. Sonst erscheint eine Kompression später als Vertretung der ganzen Gruppe.

Lu Hengs Trennung von Symbol, Macht und Ausführung dient als redaktionelle Linse, nicht als historische Zuschreibung an die RFC-Autoren. RFC 3182 brachte den Namen in RSVP. Das laufende System musste weiterhin beweisen, wer entscheiden durfte, wo die Entscheidung wirkte und was tatsächlich geschah.

Quellen und Grenzen

Die Primärakte umfasst den RFC-3182-Text, den RFC-Editor-Eintrag, den Datatracker, dessen API, Erratum 2958 und RFC 2752. Architektur und Sicherheit stammen aus RFC 2205, 2750, 2753, 2747, 4230, 4094 und dem späteren 4923. Historische Credential-Kontexte liefern RFC 1510 und 2459; die aktuelle Registrierung das IANA-Register.

Die Analyse nutzt Lu Hengs Texte über Realitätsebenen und Running-Code-Primat. Die 18 Quellen wurden am 2. Oktober 2026 in Asia/Shanghai eingefroren. Sie nennen keine konkrete Implementierung, Betreiberin, Benutzerin, Reservierung, Störung, Einführung, Interoperabilitätsmessung oder Dienstwirkung. Jeder Beleg gilt nur in seinem Umfang.