Zusammenfassung

  • CoA und Disconnect müssen für alle passenden Sitzungen als Ganzes gelingen oder ohne Teilwirkung scheitern. Mehrere Treffer sind im Protokoll vorgesehen; ein NAS ohne Mehrfachunterstützung antwortet mit Error-Cause 508.
  • Atomarität belegt die Konsistenz der Ausführung, nicht die Absicht hinter dem Selektor. Dafür müssen Attribute, Trefferzahl und jede Sitzungsidentität vor der Änderung erhalten bleiben.

„Keine Teiländerung“ klingt wie eine vollständige Sicherheitsgarantie. Tatsächlich löst sie ein engeres Problem: Ein NAS soll nicht zwei von drei ausgewählten Sitzungen ändern und die dritte in einem widersprüchlichen Zustand lassen. Ob diese drei Sitzungen überhaupt ausgewählt werden sollten, entscheidet eine frühere Schicht.

RFC 5176 erlaubt einem Dynamic Authorization Client, laufende Sitzungen zu trennen oder ihre Autorisierung zu ändern. Dazu liefert er Attribute, mit denen das NAS vorhandenen Kontext sucht. User-Name, NAS-Port, Framed-IP-Address, Calling-Station-Id, Acct-Session-Id und Chargeable-User-Identity können Teil dieser Suche sein.

Die Kardinalität ist ein Sicherheitswert

Die Suche kann keinen, einen oder mehrere Treffer liefern. Ohne Treffer folgt ein NAK. Bei mehreren Treffern gilt die Anforderung für die gesamte Menge. Kann das NAS das nicht, meldet es Multiple Session Selection Unsupported, Error-Cause 508.

Ein Betriebsmodell, das nur den Benutzernamen und das Endergebnis speichert, verliert damit den entscheidenden Zwischenwert. Ein gemeinsamer Name, wiederverwendete Attribute oder parallele Zugänge können die Wirkung vergrößern, obwohl der Request Authenticator korrekt und der Empfänger richtig war.

Die Trefferzahl gehört deshalb vor die Freigabe. Erwartet ein Auftrag genau eine Sitzung und findet das NAS drei, ist das kein informativer Hinweis nach der Ausführung, sondern eine Abweichung, die den Vorgang stoppen sollte.

Alles oder nichts auf der gewählten Menge

Alle Attribute einer CoA- oder Disconnect-Anforderung werden als verbindlich behandelt. Bei CoA sendet das NAS nur dann ACK, wenn es jede verlangte Änderung auf jeder passenden Sitzung erfolgreich ausführen kann. Andernfalls sendet es NAK und führt keine der Änderungen aus. Bei Disconnect werden entweder alle passenden Sitzungen beendet oder keine.

Das schützt vor einer halben Policy-Migration. Es schützt nicht vor einem präzise ausgeführten Irrtum. Ein ACK kann wahrheitsgemäß bestätigen, dass drei Sitzungen geändert wurden, während der Operator gedanklich nur eine adressierte. Der Widerspruch liegt zwischen Absicht und Selektor, nicht zwischen Request und NAS-Ausführung.

ACK ist Ausführungsnachweis mit begrenzter Sicht

Ein Disconnect-ACK ist mehr als eine Empfangsbestätigung: Das NAS erklärt, dass zugehöriger Sitzungskontext verworfen wurde und die gewählten Sitzungen nicht mehr verbunden sind. CoA-ACK erklärt den erfolgreichen Autorisierungswechsel. Diese Semantik darf nicht abgeschwächt werden.

Sie darf aber auch nicht auf fremde Systeme ausgedehnt werden. Accounting kann verzögert eintreffen, ein nachgelagertes Gateway eigenen Zustand halten, ein Policy-Store später replizieren und der Datenverkehr an einem anderen Punkt beobachtet werden. Der belastbare Bericht verbindet ACK mit Sitzungstabelle, Accounting und Traffic, statt eines davon durch das andere zu ersetzen.

Auch NAK hat mehrere Bedeutungen. Für Authorize Only ist CoA-ACK sogar verboten. Akzeptiert das NAS die Initiierung, antwortet es mit CoA-NAK und Error-Cause 507, Request Initiated, und sendet anschließend Access-Request. Erst Access-Accept oder Access-Reject entscheidet das Ergebnis. Das NAK ist hier ein korrekter Übergangsbeleg.

Transportvertrauen und Handlungsbefugnis

Im klassischen UDP-Modell wird über die Quelladresse ein Shared Secret gewählt und die MD5-basierte RADIUS-Konstruktion schützt den Request. Event-Timestamp und Duplikaterkennung begrenzen Replay. Trotzdem darf ein authentifizierter Client nicht automatisch alle Nutzer eines gemeinsam betriebenen NAS ändern.

RFC 9765 aktualisiert das System für RADIUS/1.1 über ausgehandeltes TLS oder DTLS. Der Kanal ersetzt die alte Paket-Authentisierung; Message-Authenticator wird nicht gesendet. Bessere Kryptografie beantwortet weiterhin nicht, welchem Realm und welchem Teilnehmer der Peer Befehle erteilen darf.

RFC 8559 trennt auch beim Proxy die Rollen. Operator-Name und ein undurchsichtiger Operator-NAS-Identifier ermöglichen den Rückweg zum richtigen NAS. Der Routing-Schlüssel ist keine eindeutige Sitzungskennung innerhalb dieses NAS.

RFC 5176 wurde als Informational veröffentlicht, weil bekannte Schwächen und Mehrdeutigkeiten eingesetzter Implementierungen nicht ohne Inkompatibilität beseitigt werden konnten. Die praktische Antwort ist kein pauschales Misstrauen. Sie besteht in begrenzten Behauptungen: Der Client belegt den Auftrag, der Proxy den Weg, das NAS die atomare Transition, Accounting und Traffic die Folgen.

Quellen