Zusammenfassung

  • Das AUTH_SESSION-Element aus RFC 3520 transportiert eine begrenzte Autorisierung aus der Sitzungssignalisierung in einen Ressourcenantrag. Eine geprüfte Signatur authentisiert die Aussage; erst lokale Policy entscheidet, ob sie die Ressource beeinflussen darf.
  • Ein belastbarer Beleg führt exakte Tokenbytes, Frische, Feldabgleich, lokale PDP-Entscheidung, PEP-Durchsetzung, RSVP-Status, SIP-Vorbedingungen, beobachteten Transport und authentisiertes Anwendungsergebnis getrennt und korreliert.

Die Ablehnung nach erfolgreicher Authentisierung wirkt nur dann überraschend, wenn ein System das Wort „gültig“ überlädt. Gültig kann bedeuten, dass die Signatur stimmt. Es kann nicht zugleich bedeuten, dass der Unterzeichner im lokalen Netz zuständig ist, die angefragten Ressourcen verfügbar sind und die Anwendung ihr Ziel erreicht hat.

RFC 3520 erschien im April 2003 auf dem Standards Track und wird heute als Proposed Standard geführt. Das Dokument definiert ein Session Authorization Policy Element. Ein Host erhält es über die Sitzungssignalisierung und kopiert es unverändert in das RSVP-Objekt POLICY_DATA. Gerade ein nicht vertrauenswürdiger Host kann so als Transporteur dienen, ohne selbst Aussteller oder Entscheider zu werden.

Standardisiert wird der Übergang einer Aussage zwischen Kontrollebenen. Der Empfänger behält die Verantwortung, Reichweite und Wirkung dieser Aussage zu bestimmen.

Die lokale Tabelle folgt auf die kryptografische Prüfung

AUTHENTICATION_DATA schützt die vorangehenden Daten des Elements. Die historische Spezifikation beschreibt Shared Key, Kerberos und Public Key. Beim Public-Key-Verfahren gehören Zertifikatspfad, Widerrufsprüfung und Signaturprüfung zum Ablauf.

Danach ist die Entscheidung nicht abgeschlossen. Sobald die Identität des Autorisierers feststeht und der Dienstantrag validiert ist, muss der Router oder Policy Decision Point lokale Policy-Tabellen heranziehen. Deren Inhalt ist ausdrücklich lokale Angelegenheit. Zusätzliche Informationen müssen sicher bezogen werden.

Kryptografie beantwortet, ob ein akzeptierter Schlüssel diese Bytes geschützt hat. Lokale Governance beantwortet, ob diese Identität diese Ressource in dieser Domäne und zu diesem Zeitpunkt binden darf. Ein positives Ergebnis der ersten Prüfung verpflichtet die zweite nicht.

Die in einem Dokument von 2003 genannten Algorithmen beschreiben dessen historischen Mechanismus. Sie sind keine aktuelle Empfehlung für kryptografische Bereitstellungen.

Der Aufbau setzt die Vertrauensbeziehung voraus

Im coupled model wirkt derselbe Policy-Server an Dienst- und Ressourcenentscheidung mit. Deshalb ist nur SESSION_ID zwingend; die Kennung verweist auf gespeicherten Entscheidungszustand. Dessen Format ist Implementierungssache, seine Haltbarkeit über Replikation und Neustart nicht.

Im associated model kommt die Identität des Autorisierers hinzu. Der Rand findet damit den Server, der die Medienentscheidung verwahrt. Kennt er nicht unabhängig, dass die Identität einen legitimen Policy-Server bezeichnet, sind Authentisierungsdaten nötig, damit kein Angreifer die Prüfung zu einem falschen Aussteller umlenkt.

Die Variante mit zwei Policy-Servern überschreitet eine administrative Grenze. Der eine versteht den Dienst, der andere kontrolliert Ressourcen. Anfrage, Antwort und lokale Übernahmebedingung sind Teile der Beweiskette. Im non-associated model kann der Prüfer keine gemeinsame Historie voraussetzen; das Token trägt daher mehr Entscheidungsdaten.

Ein einheitliches Feld „Token valid“ verdeckt, wo Vertrauen, Zustand und Ausfallrisiko in diesen Modellen liegen.

Attribute begrenzen die Erlaubnis

AUTH_SESSION kann Autorisierer, Sitzungskennung, Quell- und Zieladresse, Beginn, Ende, Ressourcen und Authentisierungsdaten enthalten. Ressourcen lassen sich als maximale Bandbreite, RSVP flow spec, SDP-Medienbeschreibung oder DSCP ausdrücken.

Im non-associated model müssen sämtliche Felder zum Ressourcenantrag passen. Quell- und Zieladresse des Datagramms müssen übereinstimmen, die angeforderte QoS darf die genehmigte nicht überschreiten. Abweichung soll zur Ablehnung führen.

Auch fehlende Portlisten haben Bedeutung. Ist für eine Seite keine Liste vorhanden, gelten nach den Regeln alle Ports dieser Seite. Ist sie vorhanden, gelten nur die genannten. Ein Audit muss daher Wert und Abwesenheit, Normalisierung, beobachteten Antrag und Vergleichsergebnis aufbewahren.

Eine korrekte Signatur für ein Ziel autorisiert kein anderes. Eine Sprachfreigabe für einen Port deckt nicht automatisch einen zweiten. Semantische Passung ist ein eigener Prüfschritt nach der Integrität.

Gegen Replay helfen Uhr oder erinnerter Zustand

Beim Erzeugen ist START_TIME oder SESSION_ID erforderlich. Eine Startzeit bindet die Entscheidung an Zeitquelle, Abweichung und Akzeptanzfenster. Im non-associated model müssen Policy-Server NTP-Synchronisation unterstützen; die RFC warnt, dass unsynchronisierte Uhren Replay ermöglichen können.

Eine Sitzungskennung verlagert die Last in gespeicherten Zustand: Wann entstand sie, wurde sie schon verwendet, erreichte dieser Zustand alle Replikate und überdauerte er Failover? Wiederholte Bytes besitzen weiterhin eine gültige Signatur. Kryptografie führt kein Nutzungsregister.

Der Beleg hält Zeitquelle, beobachteten Offset, Fenster und Replay-Entscheidung fest oder Entstehung, frühere Nutzung und dauerhafte Replikation der Kennung. RFC 5905 liefert späteren NTP-Kontext, keinen Nachweis über eine konkrete Implementierung.

Ein Router darf das Policy-Objekt ignorieren

Ein policy-aware RSVP-Router sendet die Nachricht an einen PDP und wartet auf Antwort. Ein policy-unaware Router ignoriert Policy-Datenobjekte und setzt RSVP fort. Dass AUTH_SESSION den Weg durchquert, beweist deshalb keine lückenlose Durchsetzung.

Operations müssen PEPs, zugehörige PDPs, ignorierende Knoten und installierten Reservierungszustand abbilden. Die Reise des Tokens und der Geltungsbereich der Policy sind unterschiedliche Topologiefakten.

Kann ein PDP das Element nicht verifizieren, verlangt RFC 3520 Policy Control Failure, Error Code 02, und empfiehlt genauere Angaben in AUTH_DATA. Der Code belegt einen Verifikationsfehler. Sein Ausbleiben belegt weder lokale Zustimmung noch Kapazität, vollständige Reservierung oder Anwendungserfolg.

Reservierung schließt die Sitzung nicht ab

Der Ablauf in RFC 3521 bleibt gestuft. Sitzungsmanagement kann Abschluss oder Fortschritt melden und ein Token liefern. Der Host sendet PATH. Der Rand fragt einen Policy-Server, der Ressourcen verändern kann. RESV kann nach End-to-End-Aushandlung wiederum Abschluss oder Fortschritt melden.

RFC 3312 trennt bei SIP-QoS-Vorbedingungen desired status und current status. Solange eine verpflichtende Vorbedingung unerfüllt ist, bleibt der Sitzungsaufbau ausgesetzt und Medien sollen nicht fließen. Ein Reservierungsereignis aktualisiert möglicherweise den aktuellen Status; Transportbeobachtung und Anwendungsergebnis folgen weiterhin.

Eine reservierte Warteschlange ist kein dekodiertes Gespräch. Admission ist keine Einwilligung. Eine SIP-Antwort garantiert keine dauerhafte Nutzbarkeit. Der letzte Beleg muss zur tatsächlichen Leistungszusage passen.

Eine Kette statt einer grünen Leuchte

Aufzubewahren sind ursprünglicher Sitzungsantrag, authentisierter Akteur und handelnder Principal. Hinzu kommen Identität und Reichweite des Autorisierers, Entscheidungsversion, gespeicherter Zustand, Hash der exakten Tokenbytes, Schlüssel- oder Credential-Referenz, Zertifikats- und Widerrufsergebnis sowie Replay-Entscheidung.

Quelle, Ziel, Ports, Ressourcenobergrenze und Gültigkeit werden zwischen Token und Antrag verglichen. Änderungen des PDP bleiben sichtbar. Entscheider, durchsetzender PEP und ignorierende Knoten werden erfasst; PATH, RESV und Fehler teilen eine Transaktionskorrelation.

Erst danach kommen SIP-Soll- und Ist-Zustand, beobachteter Transport und authentisierte Anwendungsbestätigung. Billing und Kundenbericht müssen benennen, welcher Beleg „abgeschlossen“ auslöst.

Nach Failover darf der Ersatzserver kein Replay wegen verlorener Historie akzeptieren. Uhrsprünge dürfen den Geltungszeitraum nicht lautlos erweitern, und neue Routen dürfen „admitted“ nicht außerhalb bekannter Durchsetzung weitertragen.

Evidenzgrenze

Dieser Artikel benennt kein Produkt, keinen Hersteller, Betreiber, Router, Policy-Server, Kunden, Nutzer, Datenstrom, Vorfall oder Einsatz. Er behauptet keine heutige Nutzung, Konformität, Sicherheit, Leistung, QoS oder geschäftliche Wirkung eines realen Systems.

RFC 3520 gilt hier als Standards-Track-Arbeit vom April 2003 mit aktuellem Status Proposed Standard. RFC 3521, 3313 und 5866 behalten Status und Reichweite. Die spezialisierte Verwaltungsdomäne aus RFC 3313 wird nicht auf das öffentliche Internet übertragen. Spätere NTP- und Diameter-Texte dienen nur dem Vergleich.

Heng Lus Texte über Autorität und running code sind offengelegte redaktionelle Perspektiven. Sie trennen formale Aussage von beobachtbarer Kontrolle, sind aber keine Quelle für IETF-Absichten.

Die enge Folgerung genügt: Ein Token kann authentisch, frisch, passend und zugelassen sein, während das Sitzungsergebnis unbelegt bleibt.

Quellen