Zusammenfassung

  • Die verzögerte Authentifizierung nach RFC 3118 beruhte auf einem vorab und außerhalb von DHCP geteilten Geheimnis zwischen Client und Server derselben Verwaltungsdomäne.
  • Bei entsprechender lokaler Richtlinie konnte der Client weiterhin ein nicht authentifiziertes Angebot annehmen; RFC 3118 empfahl eine konfigurierbare Ablehnung als Voreinstellung.

Die Option schuf keine universelle Identität

DHCP gilt als das Protokoll, mit dem ein Gerät beim Netzbeitritt eine Adresse und weitere Konfiguration erhält. Diese Bequemlichkeit bringt ein Vertrauensproblem mit sich: Ein bösartiger oder versehentlich gestarteter Server kann ein falsches Gateway, einen falschen Namensserver oder eine falsche Adresse anbieten. Ein Server kann seinerseits auf einen Client treffen, der sich als berechtigt ausgibt oder den Adresspool erschöpfen will. RFC 3118 erschien im Juni 2001 und sollte Quelle und Inhalt von DHCP-Nachrichten authentifizieren, ohne das Protokoll neu zu entwerfen.

Option 90 machte die Mechanik im Paket sichtbar: Protokollauswahl, Algorithmus, Replay-Detection-Methode, Replay-Wert und Authentifizierungsdaten. Hinter einer einzigen Option standen mehrere Fragen: Welches Verfahren kam zum Einsatz? Wie wurde eine alte Nachricht erkannt? Welcher Schlüssel verband das Paket mit seinem Gegenüber?

RFC 3118 unterschied ein einfaches Konfigurationstoken von verzögerter Authentifizierung. Das Token bot schwache Entitätsauthentifizierung, aber keine Nachrichtenauthentifizierung; das Dokument beschrieb es als rudimentären Schutz vor versehentlich gestarteten DHCP-Servern. Das verzögerte Verfahren verwendete HMAC-MD5 und ein gemeinsames Geheimnis. Das ist eine historische Entscheidung, keine Empfehlung für neue Systeme.

Die Authentifizierung begann vor der Entdeckung

Beim verzögerten Verfahren forderte der Client Authentifizierung in DHCPDISCOVER an. Ein Server wählte ein Geheimnis und gab Authentifizierungsdaten in DHCPOFFER zurück. Der Client wählte ein Angebot und sendete DHCPREQUEST mit dem dazugehörigen Geheimnis; anschließend musste er eine authentifizierte Bestätigung prüfen. Replay-Erkennung gehörte zum Austausch, damit ein gültiger Prüfwert aus einem alten Paket nicht einfach kopiert und erneut vorgelegt werden konnte.

Damit musste die Beziehung schon vor dem ersten Paket bestehen. RFC 3118 sah vor, dass der Client seinen Schlüssel außerhalb des Protokolls erhielt. Der Server musste Schlüssel berechtigter Clients kennen oder sicher abrufen können. Bei einem breit geteilten Geheimnis konnte jeder Besitzer einen anderen Besitzer imitieren; wenn einzelne Clients unterscheidbar sein sollten, verlangte RFC 3118 eindeutige Schlüssel. Der Austausch im Netz hing somit von einem Schlüsselverteilungssystem ab, das DHCP selbst nicht definierte.

Diese Grenze war beabsichtigt. RFC 3118 behandelte kein Roaming zwischen Verwaltungsdomänen. Das Verfahren zielte auf den Einsatz innerhalb einer Domäne, in der der separate Austausch eines Geheimnisses machbar war, und warnte vor schlechter Skalierung bei Clients mit Zugang zu mehreren Domänen. Ein MAC belegte, dass eine Nachricht zu einem konfigurierten Schlüssel passte; er erschuf weder globale Identität noch Roamingvereinbarung oder Nutzungsrecht für ein beliebiges Netz.

Relays und lokale Annahme gehörten ebenfalls zum Vertrauensmodell

DHCP-Relays können giaddr und hops ändern und Relay-Agent-Informationen hinzufügen. RFC 3118 legte fest, wie diese Felder in die Authentifizierungsberechnung eingingen, damit legitime Relay-Verarbeitung die Prüfung nicht ungültig machte. So wurde der Weg über Zwischenstationen definiert; dadurch wurde aber nicht jedes Relay zu einer Identitätsinstanz.

Besonders aufschlussreich war das Verhalten bei fehlender Authentifizierung. Wenn kein Angebot eine gültige Authentifizierung enthielt, konnte die lokale Richtlinie ein nicht authentifiziertes Angebot zulassen. RFC 3118 verlangte, dass Clients auf die Ablehnung solcher Nachrichten konfigurierbar waren, und empfahl die Ablehnung als Voreinstellung. Bei Annahme sollte der Client den Nutzer informieren und das Ereignis protokollieren. Sicherheit hing also auch von der lokalen Fallback-Regel ab, nicht allein vom MAC der Option.

Das Vorhandensein einer Authentifizierungsoption ist keine Garantie, dass jede angenommene Konfiguration authentifiziert wurde. RFC 3118 warnte ausdrücklich vor diesem Schluss. Die Spezifikation definierte Mechanismus und vorsichtige Voreinstellung, ließ die lokale Vertrauensentscheidung aber bei Administratoren und Client-Implementierungen.

Die Quellen belegen weder die Zahl der Implementierungen oder Konfigurationen von Option 90 noch eine gemessene Verringerung von Angriffen. Eine Spezifikation definiert mögliches Verhalten; Verbreitung und Wirkung benötigen eigene Nachweise. Die historische Aussage von RFC 3118 ist enger: DHCP-Authentifizierung blieb eine lokale Vertrauensbeziehung, begrenzt durch Schlüsselverteilung, erfasste Server und Relays sowie die Frage, ob der Client eine unsignierte Alternative akzeptierte.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3118.html
  2. https://www.rfc-editor.org/info/rfc3118
  3. https://datatracker.ietf.org/doc/rfc3118/
  4. https://www.rfc-editor.org/rfc/rfc2131.html
  5. https://www.rfc-editor.org/rfc/rfc2132.html
  6. https://www.rfc-editor.org/rfc/rfc3046.html
  7. https://www.rfc-editor.org/rfc/rfc2104.html
  8. https://www.rfc-editor.org/rfc/rfc1321.html
  9. https://www.rfc-editor.org/rfc/rfc2119.html
  10. https://www.rfc-editor.org/rfc/rfc951.html
  11. https://www.rfc-editor.org/rfc/rfc4361.html
  12. https://www.rfc-editor.org/rfc/rfc6842.html
  13. https://www.rfc-editor.org/rfc/rfc8415.html
  14. https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml