Zusammenfassung

  • FORCERENEW brachte einen konfigurierten DHCP-Client ab 2001 auf Initiative des Servers in das normale Erneuerungsverfahren zurück. Die Nachricht war weder eine neue Adresszuteilung noch der Nachweis einer abgeschlossenen Änderung.
  • Die 2012 beschriebene Nonce-Authentifizierung vermied eine vorherige Schlüsselverteilung über einen getrennten Weg. Ein während der Konfiguration übergebener Wert diente zur Prüfung späterer Rückrufe.
  • Dieser Schutz richtete sich gegen einen externen Angreifer ohne Einblick in die gewöhnlichen DHCP-Austausche. Er authentifizierte nicht unabhängig die erste Übergabe des Geheimnisses und ersetzte keine Prüfung der betrieblichen Folgen.

Eine Nachricht ohne Rückmeldung

Ein DHCP-Server hat FORCERENEW gesendet. Danach müsste vom Client eine Anfrage kommen. Bleibt sie aus, sieht der Server zunächst nur eine Lücke im erwarteten Ablauf. Er kann erneut senden, doch keine Zahl von Wiederholungen beweist, dass die Gegenstelle ihre Konfiguration verändert hat.

Die RFC 3203 vom Dezember 2001 behandelte diesen Fall ausdrücklich. Wiederholungen sollten mit exponentiell wachsendem Abstand erfolgen und zahlenmäßig begrenzt bleiben. Den ersten Abstand sollte der Server nach den Netzbedingungen wählen; einen überall geltenden Zahlenwert gab das Dokument nicht vor.

Dieser Fehlerfall erklärt die Architektur besser als der energische Name der Nachricht. FORCERENEW setzte keinen fertigen Zustand auf dem Client durch. Es sollte eine neue Interaktion auslösen. Der Server konnte deren Beginn anregen, musste aber weiterhin auf die nächste Handlung des Clients warten.

Eine fehlende Anfrage verlangt deshalb weitere Beobachtung. Die Benachrichtigung könnte verloren gegangen sein, nicht verarbeitet oder bei der Prüfung verworfen worden sein. Schweigen benennt seine Ursache nicht. Wer den Versand als erfolgreiche Umstellung verbucht, überspringt genau den Teil, in dem diese Unterschiede sichtbar würden.

Der Client musste weiterhin fragen

Der reguläre Ablauf war knapp: Der Server schickte FORCERENEW per Unicast. Der Client wechselte in den Erneuerungszustand und sendete einen gewöhnlichen DHCPREQUEST. Die Erweiterung verwendete bestehende Zustände; ihre Autoren hoben hervor, dass keine neuen Client-Zustände nötig waren.

Der Server erhielt also einen zusätzlichen Zugang zu einem vorhandenen Verfahren. Nach seiner Nachricht kehrte die Richtung des Austauschs um. Erst die Anfrage des Clients gab Anlass zur eigentlichen Antwort mit den weiteren Konsequenzen. Eine Aufforderung zum Erneuern und die Erneuerung selbst waren getrennte Ereignisse.

Sollte die Adresse wechseln, beschrieb die RFC 3203 einen längeren Weg. Der Server beantwortete die Anfrage mit DHCPNAK. Der Client ging in den Ausgangszustand zurück, sendete DHCPDISCOVER und konnte anschließend ein DHCPOFFER erhalten. FORCERENEW war nicht dieses NAK und auch kein vorweggenommenes ACK für eine neue Adresse. Eine Erneuerung konnte ebenso die bisherige Adresse beibehalten.

Früheres Erneuern war dabei nicht grundsätzlich neu. Schon die RFC 2131 vom März 1997 erlaubte dem Client einen Versuch vor T1. Neu war, dass die Initiative vom Server ausgehen konnte. Die verbleibende Gültigkeit einer Konfiguration und der Wunsch des Betreibers nach einer Änderung mussten nicht länger denselben Zeitplan haben.

Wo der Rückruf keine Zuständigkeit schafft

Die Grenze wird bei einem manuell adressierten Rechner besonders deutlich. Ein solcher Client kann DHCPINFORM nutzen, um weitere lokale Parameter zu beziehen, ohne seine Adresse durch DHCP zuteilen zu lassen. Auf FORCERENEW sollte er mit einem neuen INFORM antworten.

Die Erweiterung sollte dabei manuelle Einstellungen nicht überschreiben. Ihr Bereich blieb auf Parameter beschränkt, die sich über DHCP konfigurieren ließen. Ein Server gewann mit der Möglichkeit zum Rückruf nicht automatisch Zugriff auf alle Entscheidungen, die zuvor außerhalb seiner Zuständigkeit lagen.

Auch das Nachrichtenformat blieb im vorhandenen Rahmen. Die in RFC 2132 beschriebene Option 53 trägt den DHCP-Nachrichtentyp. FORCERENEW ergänzte darin den Wert 9. Dieser Wert ist weder eine Portnummer noch die Nummer der Authentifizierungsoption. Er benennt eine Nachricht, deren Behandlung weitere Bedingungen hat.

Die normale Zustellung war gezielt. Ein per Multicast empfangenes FORCERENEW sollte der Client laut RFC 3203 still verwerfen. Die Vorstellung eines allgemeinen Rundrufs, nach dem alle Geräte schon neu eingestellt seien, trifft weder die Zustellung noch die Wirkung des Verfahrens.

Ein kürzerer Zeitplan kann teurer werden

Als Einsatzfelder nannte das Dokument Änderungen an Diensten von Heimgateways, die Auswahl von Diensten in Hotelnetzen und eine eng kontrollierte Neunummerierung von Subnetzen. Das waren Anwendungsbeispiele einer Spezifikation. Sie belegen keine heutige Verbreitung und keine Unterstützung durch ein bestimmtes Produkt.

Die praktische Warnung stand gleich daneben: Änderungen der Adresse oder lokaler Parameter konnten laufende Sitzungen unterbrechen. Ein korrekt ausgelöster Austausch bedeutete nicht, dass Anwendungen die Umstellung ohne Folgen überstanden. Der Betreiber musste den Vorteil geringerer Wartezeit gegen diese Folgen abwägen.

Das ist mehr als ein allgemeiner Sicherheitshinweis. Mit FORCERENEW bekam die Verwaltung Einfluss auf einen Zeitpunkt, den sie sonst möglicherweise abwarten musste. Dieser Einfluss kann Wartung erleichtern, aber auch Änderungen zeitlich zusammenziehen. Das Protokoll entscheidet nicht, wie viel Gleichzeitigkeit ein Dienst verträgt.

Warum der Auslöser authentifiziert werden musste

Wer den nächsten DHCP-Austausch eines Clients zu einem selbst gewählten Zeitpunkt provozieren kann, hat bereits eine Eingriffsmöglichkeit. Dazu muss noch keine neue Adresse installiert sein. RFC 3203 verlangte deshalb die Authentifizierung von FORCERENEW und das Verwerfen erfolglos geprüfter Nachrichten.

Die Grundlage war RFC 3118 vom Juni 2001. Das Dokument enthielt Verfahren unterschiedlicher Stärke. Ein im Klartext übermitteltes Konfigurationstoken erlaubte nur eine schwache Zuordnung und keine Authentifizierung der gesamten Nachricht. Die verzögerte Authentifizierung arbeitete mit einem geteilten Geheimnis, setzte aber dessen vorherige Verteilung außerhalb von DHCP voraus.

Für die individuelle Authentifizierung von Clients mussten die entsprechenden Schlüsselbeziehungen gepflegt werden. Die kurze Benachrichtigung hing damit von Vorarbeiten ab, die in ihrem Paketformat nicht zu sehen waren. Ein Mechanismus kann auf dem Draht klein und in der Einführung aufwendig sein.

Die RFC 6704 vom August 2012 erklärte, diese Anforderung sei für den betrachteten Zweck strenger als nötig und habe die Einführung von FORCERENEW begrenzt. Das ist die damalige Einschätzung ihrer Autoren, keine aktuelle Bestandsaufnahme. Ihr Vorschlag senkte den Aufwand, indem er die Absicherung auf eine bestimmte Bedrohung ausrichtete.

Das spätere Geheimnis kam im ersten Austausch

Als Vorbild diente der historische Reconfigure-Key-Mechanismus von DHCPv6 aus RFC 3315, veröffentlicht im Juli 2003. Gemeint ist diese begrenzte technische Herkunft. Das inzwischen abgelöste Dokument ist hier keine vollständige aktuelle Anleitung für DHCPv6, und DHCPv4 übernahm nicht dessen gesamten Funktionsumfang.

Das Nonce-Verfahren wird nur verwendet, wenn die Beteiligten nicht bereits die vorherige DHCP-Authentifizierung einsetzen und sich auf das neue Verfahren geeinigt haben. Der Client zeigt die Fähigkeit in DISCOVER und REQUEST an, der Server seine Präferenz in OFFER. Eine Fähigkeitsanzeige ist noch kein Authentifizierungscode. Der Client darf die Authentifizierungsoption dieses Nonce-Protokolls nicht in seinen eigenen Nachrichten versenden.

Wenn ein neuer Wert erforderlich ist, erzeugt der Server eine starke zufällige oder pseudozufällige 128-Bit-Nonce. Er übergibt sie in einem ACK innerhalb des REQUEST–ACK-Austauschs. Beide Seiten bewahren den Wert auf. Ein späteres FORCERENEW enthält einen damit als Schlüssel berechneten HMAC, nicht erneut das Geheimnis selbst.

Damit entfällt für diesen Zweck die getrennte vorherige Schlüsselverteilung. Der erste Konfigurationsaustausch schafft die Voraussetzung für die Prüfung späterer Rückrufe. Er wird dadurch aber nicht aus einer unabhängigen Quelle vertrauenswürdig. Genau diese Verschiebung muss bei der Bewertung der Vereinfachung mitgerechnet werden.

Ohne Fähigkeitsanzeige des Clients darf der Server die entsprechende Nonce-Authentifizierung nicht einfach seinem ACK hinzufügen. Hat das anfängliche OFFER das Verfahren angekündigt, fehlt aber im folgenden ACK die gültige erwartete Information, muss der Client das ACK verwerfen und neu beginnen. Diese Regel schützt die Konsistenz der Vereinbarung. Sie bestätigt nicht von außen die Identität des zuerst antwortenden Servers.

Ein gültiger Code ist noch kein neuer Vorgang

Die Nonce kann mehrere Rückrufe schützen. Ihr Name bedeutet hier nicht, dass sie nach einer einzigen Verwendung verbraucht wäre. Im normativen Text der RFC 6704 soll ein gewöhnliches Erneuerungs-ACK den Wert nicht wiederholen, sofern kein neuer erzeugt wurde. Aus einer beispielhaften Zeichnung mit neuem Wert folgt keine Pflicht zum Wechsel bei jeder Erneuerung.

Übernimmt beim Rebinding ein anderer Server, muss dieser dagegen eine neue Nonce erzeugen. Gespeicherter Zustand und Serverwechsel gehören damit zur Funktionsfähigkeit. Eine vorhandene Authentifizierungsoption beweist nicht, dass beide Seiten nach einer Umstellung noch den passenden Zustand besitzen.

Der historische Algorithmus ist HMAC-MD5. Er authentifiziert eine Nachricht, verschlüsselt aber nicht die gesamte Kommunikation; seine Beschreibung ist keine heutige Algorithmusempfehlung. Zusätzlich wird Information zur Erkennung von Wiederholungen benötigt. Das verifizierte Erratum 3474 präzisierte 2013, dass der betreffende Zähler strikt steigen muss. Ein gleicher Wert genügt nicht, auch wenn der Code einer alten Nachricht weiterhin stimmt.

Damit sind zwei Fragen zu beantworten: Passt der Code zum gespeicherten Geheimnis, und ist der Vorgang nach den Regeln tatsächlich neu? Wer beide Prüfungen zu einem pauschalen Status „authentifiziert“ zusammenfasst, verliert einen wichtigen Teil der Erklärung für Annahme oder Ablehnung.

Der Schutz endet nicht zufällig am Netzrand

RFC 6704 betrachtete vor allem einen externen Angreifer, der die normalen Austausche zwischen Client und Server nicht beobachten kann. Ohne Kenntnis der Nonce kann er keinen passenden Rückruf erzeugen, der den Client zu einem von ihm gewählten Zeitpunkt zur Erneuerung bringt. Das Verfahren nutzt diese begrenzte Sicht des Gegners.

Wer die erste Übergabe abfangen kann, verändert die Voraussetzung. Ein Beobachter auf dem lokalen Link kann ohnehin gewöhnliche Anfragen sehen und durch Kenntnis der Nonce den vorgesehenen Schutz unterlaufen. Das Verfahren begründet weder eine unabhängige Vertrauenskette für den Start noch eine allgemeine administrative Berechtigung jedes erreichbaren Servers.

Auch die Prüfung ungültiger Nachrichten kostet Ressourcen. Eine große Menge falscher Rückrufe kann den Client belasten, selbst wenn er sie am Ende verwirft. Die Spezifikationen beschreiben diese Grenzen; sie liefern damit keinen Nachweis für einen bestimmten realen Angriff oder dessen heutige Häufigkeit.

Im IANA-Register für BOOTP- und DHCP-Parameter stehen Nachrichtentyp 9, Authentifizierungsoption 90 und Fähigkeitsoption 145 in ihren jeweiligen Bedeutungsräumen. Diese Zuordnung schafft gemeinsame Lesbarkeit, aber keine automatische Einführung. Ob ein Gerät unterstützt, verhandelt, prüft und schließlich umstellt, bleibt gesondert festzustellen.

FORCERENEW war deshalb kein verkürzter Beweis einer gelungenen Migration. Es war ein Werkzeug, um den nächsten Austausch früher zu beginnen. Das Nonce-Verfahren machte die Absicherung dieses Werkzeugs unter bestimmten Voraussetzungen einfacher. Die Anfrage des Clients, die eigentliche Konfiguration und deren Folgen blieben trotzdem nötig — auch wenn das Betriebsprotokoll zunächst nur einen einzigen Versand meldete.