Zusammenfassung

  • RFC 3495 machte DHCP-Option 122 zu einer Auswahlfläche vor der Authentisierung: Sie konnte zugelassene DHCP-Server, Provisionierungsserver, Kerberos-Realm sowie Wiederholungs- und Fristwerte vorgeben.
  • Eine spätere Zertifikatsprüfung konnte die Freischaltung bei einem feindlichen Ziel verhindern, authentisierte aber nicht rückwirkend den DHCP-Wähler und bewies auch nicht die Kundenentscheidung für den erreichten TSP.

PacketCable 1.0 teilte den Anschluss in zwei Rollen. Das Kabelmodem vermittelte den Datenzugang, der Media Terminal Adapter Medien und Signalisierung für Sprache. Beide konnten in einem Gehäuse stecken, blieben aber getrennte IP-Geräte mit eigenen MAC-Adressen, Konfigurationen und Verwaltungszuständigkeiten.

Der Data Access Provider konfigurierte das Modem, der Telephony Service Provider den MTA. RFC 3495 hielt fest, dass die Stelle mit Kontrolle über die Modemkonfiguration auch bestimmte, welche Unternehmen die MTA-Konfiguration beherrschen durften. Der technische Startvorgang verteilte damit wirtschaftliche Befugnis.

IANA vergab Code 122 an CableLabs Client Configuration. Die typisierten Unteroptionen nannten primäre und sekundäre TSP-DHCP-Server, einen Provisionierungsserver, den Kerberos-Realm, die Nutzung des Ticket-Granting-Servers, AS- und AP-Wiederholungen und einen Provisionierungstimer. Der frühere standortspezifische Code 177 wurde aufgegeben.

Das Format war genau. IPv4-Adressen bestanden aus vier Oktetten in Netzwerkreihenfolge. FQDNs folgten RFC 1035, endeten mit Null und durften keine Namenskompression verwenden. Für mehr als 255 Oktette galt RFC 3396. Doch eine syntaktisch korrekte Anweisung bewies weder die Existenz noch die Berechtigung ihres Ziels.

Auch die Schreibrichtung ordnete Verantwortung zu. Clients forderten CCC über die Parameterliste an und meldeten ihre Geräteklasse; der Server füllte die Unteroptionen nach CableLabs-Regeln. Der Client setzte CCC nie in seine Anfrage. Ein Realm im Mitschnitt war somit die Aussage einer antwortenden Konfigurationsinstanz, keine unabhängige Wahl des Teilnehmers.

RFC 3495 benannte die Fehlleitung ausdrücklich. Falsche DHCP- oder Provisionierungsadressen konnten Dienstverweigerung auslösen. Eine Adresse eines Lauscher-Systems eröffnete einen Mittelsmannpfad. Ein falscher Realm lenkte den MTA zu einem anderen KDC. Ein böswilliger TSP konnte die Zuordnung ändern und einen Kunden vom gewählten Anbieter abziehen.

Die erste Abwehrschicht lag beim CMTS. Es sollte Anfragen nur an ausdrücklich konfigurierte DHCP-Server weiterleiten und abwärts nur Verkehr zugelassener Adressbereiche passieren lassen. Das war eine Betreiberbedingung. Ob sie erfüllt war, zeigten aktive Konfiguration, Filterzustand und Verkehr – nicht Option 122.

Die zweite Schicht folgte später. Selbst nach einer Fehlleitung zum KDC musste der MTA gültige Zertifikate vorlegen, bevor der Dienst freigeschaltet wurde. Das konnte eine unberechtigte Gegenstelle stoppen. Die Prüfung kostete jedoch Rechenleistung und konnte selbst zur Dienstverweigerung beitragen. Eine Ablehnung bewies das Scheitern am späteren Tor, nicht die Echtheit des früheren Realm-Werts.

Ein angenommenes Zertifikat bewies ebenso wenig den Auftrag des Kunden. Das Dokument erwog einen böswilligen, aber zertifizierten TSP, setzte friedliches Zusammenleben zugelassener Anbieter voraus und verwies Kundenumleitung in die administrative Klärung. Kryptografische Identität, Netzzulassung und kommerzielle Zustimmung blieben getrennt.

Wiederholungen vervielfachten die Folgen. AS- und AP-Austausch erhielten jeweils Anfangswartezeit, Obergrenze und Versuchszahl. Nach Ablauf des äußeren Provisionierungstimers begann der gesamte Ablauf erneut. Null schaltete diese Frist ab; der Wert bescheinigte keinen erfolgreichen Abschluss.

Benachbarte RFCs hatten andere Gegenstände. RFC 3361 fand SIP-Serverkandidaten, RFC 3396 setzte lange Optionen zusammen, RFC 3397 lieferte Suchdomänen und RFC 3442 Routen. RFC 3495 regelte die Vertrauenslenkung davor: DHCP bestimmte, welchem Realm und welchem Endpunkt die spätere Authentisierung überhaupt begegnete.

Die Beweiskette muss jeden Übergang behalten: Optionsbytes, Analyse, Realm- und Endpunktwahl, Auflösung und Route, KDC-Kontakt, Zertifikats- und Kerberos-Erfolg, Dienstticket, rechtzeitige Provisionierung, kundenautorisierter TSP und gelieferter Telefondienst. Kein früher Beleg ersetzt den folgenden.

Quellen