21. Authentifizierung von DHCP-Nachrichten

Einige Netzwerkadministratoren möchten möglicherweise eine Authentifizierung der Quelle und des Inhalts von DHCP-Nachrichten bereitstellen. Beispielsweise können Clients durch die Verwendung gefälschter DHCP-Server Denial-of-Service-Angriffen ausgesetzt sein oder einfach aufgrund versehentlich instanziierter DHCP-Server falsch konfiguriert werden. Netzwerkadministratoren möchten möglicherweise die Zuweisung von Adressen auf autorisierte Hosts beschränken, um Denial-of-Service-Angriffe in "feindlichen" Umgebungen zu vermeiden, in denen das Netzwerkmedium nicht physisch gesichert ist, wie z. B. drahtlose Netzwerke oder Studentenwohnheime.

Der DHCP-Authentifizierungsmechanismus basiert auf dem Design der Authentifizierung für DHCPv4 [4].

21.1. Sicherheit von Nachrichten, die zwischen Servern und Relay-Agents gesendet werden

Relay-Agents und Server, die Nachrichten sicher austauschen, verwenden die IPsec-Mechanismen für IPv6 [7]. Wenn eine Client-Nachricht über mehrere Relay-Agents weitergeleitet wird, muss jeder der Relay-Agents unabhängige, paarweise Vertrauensbeziehungen etabliert haben. Das heißt, wenn Nachrichten vom Client C von Relay-Agent A an Relay-Agent B und dann an den Server weitergeleitet werden, müssen Relay-Agents A und B so konfiguriert sein, dass sie IPSec für die Nachrichten verwenden, die sie austauschen, und Relay-Agent B und der Server müssen so konfiguriert sein, dass sie IPSec für die Nachrichten verwenden, die sie austauschen.

Relay-Agents und Server, die sichere Relay-Agent-zu-Server- oder Relay-Agent-zu-Relay-Agent-Kommunikation unterstützen, verwenden IPsec unter den folgenden Bedingungen:

Selektoren (Selectors): Relay-Agents werden manuell mit den Adressen des Relay-Agents oder Servers konfiguriert, an den DHCP-Nachrichten weitergeleitet werden sollen. Jeder Relay-Agent und Server, der IPsec zum Sichern von DHCP-Nachrichten verwenden wird, muss auch mit einer Liste der Relay-Agents konfiguriert werden, an die Nachrichten zurückgegeben werden. Die Selektoren für die Relay-Agents und Server sind die Adresspaare, die Relay-Agents und Server definieren, die DHCP-Nachrichten auf den DHCPv6-UDP-Ports 546 und 547 austauschen.

Modus (Mode): Relay-Agents und Server verwenden den Transportmodus und ESP. Die Informationen in DHCP-Nachrichten werden im Allgemeinen nicht als vertraulich angesehen, daher muss keine Verschlüsselung verwendet werden (d. h., NULL-Verschlüsselung kann verwendet werden).

Schlüsselverwaltung (Key management): Da die Relay-Agents und Server innerhalb einer Organisation verwendet werden, sind Public-Key-Schemata nicht erforderlich. Da die Relay-Agents und Server manuell konfiguriert werden müssen, kann eine manuell konfigurierte Schlüsselverwaltung ausreichen, bietet jedoch keinen Schutz gegen wiederholte Nachrichten. Dementsprechend SOLLTE IKE mit vorab geteilten Geheimnissen unterstützt werden. IKE mit öffentlichen Schlüsseln KANN unterstützt werden.

Sicherheitsrichtlinie (Security policy): DHCP-Nachrichten zwischen Relay-Agents und Servern sollten nur von DHCP-Peers akzeptiert werden, wie sie in der lokalen Konfiguration identifiziert werden.

Authentifizierung (Authentication): Gemeinsam genutzte Schlüssel, die auf die Quell-IP-Adresse der empfangenen DHCP-Nachricht indiziert sind, sind in dieser Anwendung ausreichend.

Verfügbarkeit (Availability): Geeignete IPsec-Implementierungen sind wahrscheinlich für Server und für Relay-Agents in funktionsreicheren Geräten verfügbar, die in Unternehmens- und Kern-ISP-Netzwerken verwendet werden. IPsec ist weniger wahrscheinlich für Relay-Agents in Low-End-Geräten verfügbar, die hauptsächlich auf Heim- oder kleinen Büromärkten verwendet werden.

21.2. Zusammenfassung der DHCP-Authentifizierung

Die Authentifizierung von DHCP-Nachrichten wird durch die Verwendung der Authentication-Option (siehe Abschnitt 22.11) erreicht. Die in der Authentication-Option enthaltenen Authentifizierungsinformationen können verwendet werden, um die Quelle einer DHCP-Nachricht zuverlässig zu identifizieren und zu bestätigen, dass der Inhalt der DHCP-Nachricht nicht manipuliert wurde.

Die Authentication-Option bietet einen Rahmen für mehrere Authentifizierungsprotokolle. Zwei solche Protokolle sind hier definiert. Andere in Zukunft definierte Protokolle werden in separaten Dokumenten spezifiziert.

Jede DHCP-Nachricht DARF NICHT mehr als eine Authentication-Option enthalten.

Das Protokollfeld in der Authentication-Option identifiziert das spezifische Protokoll, das verwendet wird, um die in der Option enthaltenen Authentifizierungsinformationen zu generieren. Das Algorithmusfeld identifiziert einen spezifischen Algorithmus innerhalb des Authentifizierungsprotokolls; beispielsweise gibt das Algorithmusfeld den Hash-Algorithmus an, der verwendet wird, um den Message Authentication Code (MAC) in der Authentifizierungsoption zu generieren. Das Replay Detection Method (RDM)-Feld gibt den Typ der Replay-Erkennung an, die im Replay-Erkennungsfeld verwendet wird.

21.3. Replay-Erkennung

Das Replay Detection Method (RDM)-Feld bestimmt den Typ der Replay-Erkennung, die im Replay-Erkennungsfeld verwendet wird.

Wenn das RDM-Feld 0x00 enthält, MUSS das Replay-Erkennungsfeld auf den Wert eines monoton steigenden Zählers gesetzt werden. Die Verwendung eines Zählerwerts, wie z. B. der aktuellen Tageszeit (z. B. ein NTP-Format-Zeitstempel [9]), kann die Gefahr von Replay-Angriffen verringern. Diese Methode MUSS von allen Protokollen unterstützt werden.

21.4. Delayed Authentication Protocol

Wenn das Protokollfeld 2 ist, verwendet die Nachricht den "Delayed Authentication"-Mechanismus. Bei der verzögerten Authentifizierung fordert der Client die Authentifizierung in seiner Solicit-Nachricht an, und der Server antwortet mit einer Advertise-Nachricht, die Authentifizierungsinformationen enthält. Diese Authentifizierungsinformationen enthalten einen von der Quelle generierten Nonce-Wert als Message Authentication Code (MAC), um Nachrichtenauthentifizierung und Entitätsauthentifizierung bereitzustellen.

Die Verwendung einer bestimmten Technik, die auf dem HMAC-Protokoll [8] unter Verwendung des MD5-Hash [16] basiert, ist hier definiert.

21.4.1. Verwendung der Authentication-Option im Delayed Authentication Protocol

In einer Solicit-Nachricht füllt der Client die Felder protocol, algorithm und RDM in der Authentication-Option mit den Präferenzen des Clients aus. Der Client setzt das Replay-Erkennungsfeld auf Null und lässt das Authentifizierungsinformationsfeld weg. Der Client setzt das option-len-Feld auf 11.

In allen anderen Nachrichten identifizieren die Felder protocol und algorithm die Methode, die verwendet wird, um den Inhalt des Authentifizierungsinformationsfeldes zu konstruieren. Das RDM-Feld identifiziert die Methode, die verwendet wird, um den Inhalt des Replay-Erkennungsfeldes zu konstruieren.

Das Format der Authentifizierungsinformationen ist:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          DHCP-Realm                           |
 |                      (variable Länge)                         |
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            Schlüssel-ID                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                           HMAC-MD5                            |
 |                          (128 Bits)                           |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DHCP-Realm: Der DHCP-Realm, der den Schlüssel identifiziert, der verwendet wird, um den HMAC-MD5-Wert zu generieren.

Schlüssel-ID (key ID): Der Schlüsselidentifikator, der den Schlüssel identifiziert, der verwendet wird, um den HMAC-MD5-Wert zu generieren.

HMAC-MD5: Der Message Authentication Code, der durch Anwenden von MD5 auf die DHCP-Nachricht unter Verwendung des durch den DHCP-Realm, Client-DUID und Schlüssel-ID identifizierten Schlüssels generiert wird.

Der Sender berechnet den MAC unter Verwendung des HMAC-Generierungsalgorithmus [8] und der MD5-Hash-Funktion [16]. Die gesamte DHCP-Nachricht (wobei das MAC-Feld der Authentication-Option auf Null gesetzt wird), einschließlich des DHCP-Nachrichtenheaders und des Optionsfeldes, wird als Eingabe für die HMAC-MD5-Berechnungsfunktion verwendet.

DISKUSSION:

Algorithmus 1 spezifiziert die Verwendung von HMAC-MD5. Die Verwendung einer anderen Technik, wie z. B. HMAC-SHA, wird als separates Protokoll spezifiziert.

Der DHCP-Realm, der zur Identifizierung von Authentifizierungsschlüsseln verwendet wird, wird so gewählt, dass er unter administrativen Domänen eindeutig ist. Die Verwendung des DHCP-Realm ermöglicht es DHCP-Administratoren, Konflikte bei der Verwendung von Schlüsselidentifikatoren zu vermeiden, und ermöglicht es einem Host, der DHCP verwendet, authentifiziertes DHCP zu verwenden, während er zwischen DHCP-Administrationsdomänen roamt.

21.4.2. Nachrichtenvalidierung

Jede DHCP-Nachricht, die mehr als eine Authentication-Option enthält, MUSS verworfen werden.

Um eine eingehende Nachricht zu validieren, überprüft der Empfänger zunächst, dass der Wert im Replay-Erkennungsfeld gemäß der durch das RDM-Feld angegebenen Replay-Erkennungsmethode akzeptabel ist. Als nächstes berechnet der Empfänger den MAC wie in [8] beschrieben. Die gesamte DHCP-Nachricht (wobei das MAC-Feld der Authentication-Option auf 0 gesetzt wird) wird als Eingabe für die HMAC-MD5-Berechnungsfunktion verwendet. Wenn der vom Empfänger berechnete MAC nicht mit dem in der Authentication-Option enthaltenen MAC übereinstimmt, MUSS der Empfänger die DHCP-Nachricht verwerfen.

21.4.3. Schlüsselnutzung

Jeder DHCP-Client hat einen Satz von Schlüsseln. Jeder Schlüssel wird durch <DHCP-Realm, Client-DUID, Schlüssel-ID> identifiziert. Jeder Schlüssel hat auch eine Lebensdauer. Der Schlüssel darf nicht über das Ende seiner Lebensdauer hinaus verwendet werden. Die Schlüssel des Clients werden zunächst über einen Out-of-Band-Mechanismus an den Client verteilt. Die Lebensdauer für jeden Schlüssel wird mit dem Schlüssel verteilt. Mechanismen für Schlüsselverteilung und Lebensdauerspezifikation liegen außerhalb des Geltungsbereichs dieses Dokuments.

Der Client und der Server verwenden einen der Schlüssel des Clients, um DHCP-Nachrichten während einer Sitzung zu authentifizieren (bis zur nächsten vom Client gesendeten Solicit-Nachricht).

21.4.4. Client-Überlegungen für das Delayed Authentication Protocol

Der Client kündigt seine Absicht an, DHCP-Authentifizierung zu verwenden, indem er eine Authentication-Option in seine Solicit-Nachricht aufnimmt. Der Server wählt einen Schlüssel für den Client basierend auf der DUID des Clients aus. Der Client und der Server verwenden diesen Schlüssel, um alle während der Sitzung ausgetauschten DHCP-Nachrichten zu authentifizieren.

21.4.4.1. Senden von Solicit-Nachrichten

Wenn der Client eine Solicit-Nachricht sendet und Authentifizierung verwenden möchte, fügt er eine Authentication-Option mit dem gewünschten Protokoll, Algorithmus und RDM wie in Abschnitt 21.4 beschrieben hinzu. Der Client fügt keine Replay-Erkennung oder Authentifizierungsinformationen in die Authentication-Option ein.

21.4.4.2. Empfangen von Advertise-Nachrichten

Der Client validiert alle Advertise-Nachrichten, die eine Authentication-Option enthalten, die das verzögerte Authentifizierungsprotokoll spezifiziert, unter Verwendung des in Abschnitt 21.4.2 beschriebenen Validierungstests.

Das Client-Verhalten, wenn keine Advertise-Nachrichten Authentifizierungsinformationen enthalten oder den Validierungstest bestehen, wird durch lokale Richtlinien auf dem Client gesteuert. Gemäß der Client-Richtlinie KANN der Client wählen, auf eine Advertise-Nachricht zu antworten, die nicht authentifiziert wurde.

Die Entscheidung, lokale Richtlinien so zu setzen, dass nicht authentifizierte Nachrichten akzeptiert werden, sollte mit Vorsicht getroffen werden. Das Akzeptieren einer nicht authentifizierten Advertise-Nachricht kann den Client anfällig für Spoofing und andere Angriffe machen. Wenn lokale Benutzer nicht ausdrücklich darüber informiert werden, dass der Client eine nicht authentifizierte Advertise-Nachricht akzeptiert hat, können die Benutzer fälschlicherweise annehmen, dass der Client eine authentifizierte Adresse erhalten hat und nicht DHCP-Angriffen durch nicht authentifizierte Nachrichten ausgesetzt ist.

Ein Client MUSS konfigurierbar sein, um nicht authentifizierte Nachrichten zu verwerfen, und SOLLTE standardmäßig so konfiguriert sein, dass er nicht authentifizierte Nachrichten verwirft, wenn der Client mit einem Authentifizierungsschlüssel oder anderen Authentifizierungsinformationen konfiguriert wurde. Ein Client KANN wählen, zwischen Advertise-Nachrichten ohne Authentifizierungsinformationen und Advertise-Nachrichten, die den Validierungstest nicht bestehen, zu unterscheiden; beispielsweise könnte ein Client erstere akzeptieren und letztere verwerfen. Wenn ein Client eine nicht authentifizierte Nachricht akzeptiert, SOLLTE der Client alle lokalen Benutzer informieren und SOLLTE das Ereignis protokollieren.

21.4.4.3. Senden von Request-, Confirm-, Renew-, Rebind-, Decline- oder Release-Nachrichten

Wenn der Client die Advertise-Nachricht authentifiziert hat, über die der Client den Server ausgewählt hat, MUSS der Client Authentifizierungsinformationen für nachfolgende Request-, Confirm-, Renew-, Rebind- oder Release-Nachrichten generieren, die an den Server gesendet werden, wie in Abschnitt 21.4 beschrieben. Wenn der Client eine nachfolgende Nachricht sendet, MUSS er denselben Schlüssel verwenden, den der Server zum Generieren der Authentifizierungsinformationen verwendet hat.

21.4.4.4. Senden von Information-request-Nachrichten

Wenn der Server in einem vorherigen Nachrichtenaustausch einen Schlüssel für den Client ausgewählt hat (siehe Abschnitt 21.4.5.1), MUSS der Client denselben Schlüssel verwenden, um die Authentifizierungsinformationen während der gesamten Sitzung zu generieren.

21.4.4.5. Empfangen von Reply-Nachrichten

Wenn der Client das von ihm akzeptierte Advertise authentifiziert hat, MUSS der Client die zugehörige Reply-Nachricht vom Server validieren. Der Client MUSS die Reply verwerfen, wenn die Nachricht den Validierungstest nicht besteht, und KANN den Validierungsfehler protokollieren. Wenn die Reply den Validierungstest nicht besteht, MUSS der Client den DHCP-Konfigurationsprozess neu starten, indem er eine Solicit-Nachricht sendet.

Wenn der Client eine Advertise-Nachricht akzeptiert hat, die keine Authentifizierungsinformationen enthielt oder den Validierungstest nicht bestanden hat, KANN der Client eine nicht authentifizierte Reply-Nachricht vom Server akzeptieren.

21.4.4.6. Empfangen von Reconfigure-Nachrichten

Der Client MUSS die Reconfigure verwerfen, wenn die Nachricht den Validierungstest nicht besteht, und KANN den Validierungsfehler protokollieren.

21.4.5. Server-Überlegungen für das Delayed Authentication Protocol

Nach Erhalt einer Solicit-Nachricht, die eine Authentication-Option enthält, wählt der Server einen Schlüssel für den Client aus, basierend auf der DUID des Clients und den Schlüsselauswahlrichtlinien, mit denen der Server konfiguriert wurde. Der Server identifiziert den ausgewählten Schlüssel in der Advertise-Nachricht und verwendet den Schlüssel, um nachfolgende Nachrichten zwischen dem Client und dem Server zu validieren.

21.4.5.1. Empfangen von Solicit-Nachrichten und Senden von Advertise-Nachrichten

Der Server wählt einen Schlüssel für den Client aus und fügt Authentifizierungsinformationen in die an den Client zurückgegebene Advertise-Nachricht ein, wie in Abschnitt 21.4 spezifiziert. Der Server MUSS den Identifikator des für den Client ausgewählten Schlüssels aufzeichnen und denselben Schlüssel zur Validierung nachfolgender Nachrichten mit dem Client verwenden.

21.4.5.2. Empfangen von Request-, Confirm-, Renew-, Rebind- oder Release-Nachrichten und Senden von Reply-Nachrichten

Der Server verwendet den in der Nachricht identifizierten Schlüssel und validiert die Nachricht wie in Abschnitt 21.4.2 spezifiziert. Wenn die Nachricht den Validierungstest nicht besteht oder der Server den durch das Feld 'key ID' identifizierten Schlüssel nicht kennt, MUSS der Server die Nachricht verwerfen und KANN wählen, den Validierungsfehler zu protokollieren.

Wenn die Nachricht den Validierungstest besteht, antwortet der Server auf die spezifische Nachricht wie in Abschnitt 18.2 beschrieben. Der Server MUSS Authentifizierungsinformationen einschließen, die unter Verwendung des in der empfangenen Nachricht identifizierten Schlüssels generiert wurden, wie in Abschnitt 21.4 spezifiziert.

21.5. Reconfigure Key Authentication Protocol

Das Reconfigure Key Authentication Protocol bietet Schutz vor Fehlkonfiguration eines Clients, die durch eine von einem bösartigen DHCP-Server gesendete Reconfigure-Nachricht verursacht wird. In diesem Protokoll sendet ein DHCP-Server einen Reconfigure Key an den Client im anfänglichen Austausch von DHCP-Nachrichten. Der Client zeichnet den Reconfigure Key zur Verwendung bei der Authentifizierung nachfolgender Reconfigure-Nachrichten von diesem Server auf. Der Server fügt dann ein aus dem Reconfigure Key berechnetes HMAC in nachfolgende Reconfigure-Nachrichten ein.

Sowohl der vom Server an den Client gesendete Reconfigure Key als auch das HMAC in nachfolgenden Reconfigure-Nachrichten werden als Authentifizierungsinformationen in einer Authentication-Option übertragen. Das Format der Authentifizierungsinformationen ist im folgenden Abschnitt definiert.

Das Reconfigure Key Protocol wird (vom Server initiiert) nur verwendet, wenn der Client und der Server kein anderes Authentifizierungsprotokoll verwenden und der Client und der Server vereinbart haben, Reconfigure-Nachrichten zu verwenden.

21.5.1. Verwendung der Authentication-Option im Reconfigure Key Authentication Protocol

Die folgenden Felder werden in einer Authentication-Option für das Reconfigure Key Authentication Protocol gesetzt:

• protocol: 3
• algorithm: 1
• RDM: 0

Das Format der Authentifizierungsinformationen für das Reconfigure Key Authentication Protocol ist:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |                 Wert (128 Bits)               |
 +-+-+-+-+-+-+-+-+                                               |
 .                                                               .
 .                                                               .
 .                                               +-+-+-+-+-+-+-+-+
 |                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: Typ der Daten im Value-Feld, die in dieser Option übertragen werden:

• 1: Reconfigure Key-Wert (verwendet in Reply-Nachricht).
• 2: HMAC-MD5-Digest der Nachricht (verwendet in Reconfigure-Nachricht).

Wert (Value): Daten wie durch Feld definiert.

21.5.2. Server-Überlegungen für das Reconfigure Key Protocol

Der Server wählt einen Reconfigure Key für einen Client während des Request/Reply-, Solicit/Reply- oder Information-request/Reply-Nachrichtenaustauschs aus. Der Server zeichnet den Reconfigure Key auf und überträgt diesen Schlüssel an den Client in einer Authentication-Option in der Reply-Nachricht.

Der Reconfigure Key ist 128 Bits lang und MUSS eine kryptographisch starke Zufalls- oder Pseudozufallszahl sein, die nicht leicht vorhergesagt werden kann.

Um eine Authentifizierung für eine Reconfigure-Nachricht bereitzustellen, wählt der Server einen Replay-Erkennungswert gemäß dem vom Server ausgewählten RDM aus und berechnet ein HMAC-MD5 der Reconfigure-Nachricht unter Verwendung des Reconfigure Key für den Client. Der Server berechnet das HMAC-MD5 über die gesamte DHCP-Reconfigure-Nachricht, einschließlich der Authentication-Option; das HMAC-MD5-Feld in der Authentication-Option wird für die HMAC-MD5-Berechnung auf Null gesetzt. Der Server fügt das HMAC-MD5 in das Authentifizierungsinformationsfeld einer Authentication-Option ein, die in der an den Client gesendeten Reconfigure-Nachricht enthalten ist.

21.5.3. Client-Überlegungen für das Reconfigure Key Protocol

Der Client erhält einen Reconfigure Key vom Server in der anfänglichen Reply-Nachricht vom Server. Der Client zeichnet den Reconfigure Key zur Verwendung bei der Authentifizierung nachfolgender Reconfigure-Nachrichten auf.

Um eine Reconfigure-Nachricht zu authentifizieren, berechnet der Client ein HMAC-MD5 über die DHCP-Reconfigure-Nachricht unter Verwendung des vom Server erhaltenen Reconfigure Key. Wenn dieses berechnete HMAC-MD5 mit dem Wert in der Authentication-Option übereinstimmt, akzeptiert der Client die Reconfigure-Nachricht.