Zusammenfassung

  • Die zwei definierten Bits des Ticket Control Mask treffen das Provisioning-Server-Ticket beziehungsweise die Gruppe der Call-Management-Server-Tickets im persistenten Gerätespeicher. Daraus folgt keine universelle Sperre und kein Abbau einer laufenden Association.
  • Unbekannte Bits und Geräte ohne lokalen Ticketspeicher haben vorgeschriebenes Ignorierverhalten. Nur ein Parser- und Speicherbeleg zeigt deshalb, ob ein zugestelltes DHCP-Objekt tatsächlich Zustand änderte.

Ein Change-Datensatz enthält 09 02 00 03. Vier Bytes können eindeutig sein, ohne vollständig zu sein. Sie bezeichnen Code, Länge und zwei gesetzte Auswahlbits. Sie enthalten weder die Identität eines neuen Tickets noch eine Antwort des KDC, eine SA-ID oder einen erfolgreichen Diensttest.

RFC 3594 erschien im September 2003 als Standards Track. Die Spezifikation erweitert die DHCP CableLabs Client Configuration Option um Security Ticket Control. Gerade weil die Wire-Semantik so kompakt ist, eignet sie sich als Lehrstück für belastbare Änderungsnachweise.

Exakte Bits verhindern erfundene Postconditions

Bit 0 bezeichnet das vom Gerät verwendete PacketCable Provisioning Server Ticket. Bit 1 bezeichnet alle vom Gerät verwendeten Call Management Server Tickets. Bit 2 bis 15 waren reserviert und mussten beim Senden null sein. Eine Eins verlangt die sofortige Invalidierung des betreffenden lokal persistenten Tickets oder der Gruppe; eine Null überlässt die Behandlung den normalen Regeln.

Der Audit-Datensatz darf diese Maske nicht zu „Credential Reset“ vereinfachen. Bit 0 und Bit 1 haben verschiedene Abhängigkeiten und potenziell verschiedene Mengen. Für eine Kapazitätsrechnung braucht man die Rohbytes, die ausgewählte Klasse, vorherige Anzahl und Ablaufzeiten sowie die Boot-Epoche des Geräts.

Eine Null bestätigt keine weltweite Gültigkeit. Ablauf, Schlüsselwechsel oder lokale Regeln können das Ticket dennoch unbrauchbar machen. Umgekehrt macht eine Eins nur die lokale persistente Darstellung ungültig. Sie erklärt nicht, was KDC und Anwendungsserver über dieselbe Berechtigung wissen.

Hat ein Gerät keinen lokalen Ticketspeicher, muss es die Suboption ignorieren. Unbekannte Bitwerte muss es ebenfalls ignorieren. Paketempfang und Zustandsänderung sind damit nachweislich verschiedene Ereignisse. Konformität kann in einem korrekten Nichtstun bestehen.

Persistenz war ein Lastverteilungsmechanismus

PacketCable-Geräte konnten gültige Kerberos-Tickets über einen Neustart hinweg wiederverwenden. Bei PKINIT vermied das erneute Public-Key-Operationen. Die spätere CableLabs Security Specification verlangt für ein MTA das Provisioning-Ticket und Kapazität für genügend CMS-Tickets.

Persistenz spart also nicht nur Millisekunden auf einem Endgerät. Sie verschiebt Arbeit aus dem gemeinsamen Startpfad und verteilt den Bedarf über die Zeit. Eine gleichzeitige Invalidierung zieht diese verteilte Arbeit wieder an einen zentralen Zeitpunkt.

RFC 3594 warnt vor vielen zurückgesetzten oder eingeschalteten MTAs, denen ein bösartiger DHCP-Server die Invalidierung aller Tickets befiehlt. Wenn sie anschließend gleichzeitig authentisieren und Tickets beziehen, kann die Sicherheitsinfrastruktur in einen Denial of Service geraten. Die einzelnen Anforderungen müssen dafür nicht falsch sein.

Auch ein autorisierter Change kann dieses Muster ohne Cohorts und Jitter erzeugen. Die spätere CableLabs-Spezifikation bewahrt bei einem routinemäßigen Service-Key-Wechsel ältere gültige Schlüssel mindestens über die Ticket-Lebensdauer auf, damit nicht viele MTAs plötzlich den KDC mit PKINIT-Anforderungen fluten. Übergangskompatibilität wirkt hier als Laststeuerung.

Ein Rollout-Plan braucht daher Arrival-Rate, Krypto-CPU, Queue-Limit, Backoff-Verteilung, Failover-Reserve und automatische Stopps. „Masken gesendet“ ist keine Erfolgsmetrik.

Speicher, Ticket, Association und Anwendung

Die Suboption adressiert den nichtflüchtigen Ticketbestand des Clients. Sie trägt keine KDC-Antwort, keinen AP-Austausch, keine SA-Kennung und kein Anwendungsergebnis. RFC 3594 behauptet weder das Löschen einer In-Memory-Kopie noch die Änderung eines Server-Schlüssels oder den Abbau bestehender IPsec-SAs.

Der spätere primäre CableLabs-Text erklärt, dass ein PKINIT-Austausch mit einem neuen Ticket enden kann, ohne vorhandene Sicherheitsparameter zu beeinflussen. Das Ticket ist Input für nachfolgende Phasen, aber kein Beleg über deren Ausgang.

Ein belastbares Modell führt vier unabhängige Zustände: persistentes Ticket invalidiert, Ersatzticket erhalten, Association neu aufgebaut, Dienst verifiziert. Jeder Zustand besitzt einen eigenen Zeitstempel, Owner und Fehler. Ein erfolgreicher erster Schritt darf den vierten nicht grün färben.

Das macht auch die Irreversibilität sichtbar. Ein UI-Rollback stellt kein gelöschtes Ticket wieder her. Nach der Löschung müssen Erwerb, Association und Anwendungstest erneut durchlaufen werden; bereits ausgelöste Retries bleiben Teil der Last.

Die Vertrauensgrenze ist eine überprüfbare Annahme

Die RFC hält den bösartigen DHCP-Fall in der beschriebenen Kabelarchitektur für unwahrscheinlich. Ein korrekt konfigurierter CMTS leitet Anfragen nur an festgelegte DHCP-Adressen weiter und lässt Downstream-Verkehr nur von bestimmten Quellen zu. Zugleich schützt diese Filterung nicht vor einem gefälschten Server hinter dem CMTS; dort wird ein eng kontrolliertes Provider-Netz angenommen.

Aus „angenommen“ darf kein heutiger Messwert werden. Der Change muss autoritativen Server, Relay, CMTS-Pfad, Filterversion, Quelle und Client-Transaction belegen. DHCP Authentication aus RFC 3118 ist eine weitere Schicht; Standardisierung beweist ihren Einsatz nicht.

Der IANA-Eintrag für Suboption 9 belegt koordinierte Syntax. Er attestiert weder Firmware-Unterstützung noch Zustellung, Parsing, Speichermutation oder KDC-Kapazität.

Beweisgrenze

Dieser Artikel nennt keinen Betreiber, kein MTA-Modell, keinen CMTS, kein DHCP-Produkt, keinen KDC, CMS, Teilnehmer, Anruf, Vorfall oder Marktanteil. Standards Track ist kein Deployment-Beleg.

RFC 3495 definiert die übergeordnete Option; RFC 2131 liefert DHCP; RFC 3118 die getrennte Authentisierung. RFC 1510 ist der historische Kerberos-Bezug, RFC 4120 die spätere Fassung. RFC 3634 behandelt eine andere CableLabs-Suboption. RFC 2434 und RFC 8126 dokumentieren Registry-Regeln. Die CableLabs-Spezifikation von 2005 ist späterer Primärkontext und erweitert RFC 3594 nicht rückwirkend.

Heng Lus Texte über Running-Code-Primat und minimale Anfangsspezifikationen sind offengelegte redaktionelle Linsen. Sie schärfen die Frage nach ausgeführtem Verhalten und einer schmalen gemeinsamen Regel, belegen aber weder Autorenabsicht noch Deployment.

Der genaue Abschluss lautet: Das lokale persistente Ticket wurde invalidiert. Für Ersatz, Association, Kapazität und Dienst stehen die Belege noch aus.

Sources