21. Authentifizierung von DHCP-Nachrichten (Authentication of DHCP Messages)
- Authentifizierung von DHCP-Nachrichten
Einige Netzwerkadministratoren wünschen möglicherweise eine Authentifizierung der Quelle und der Inhalte von DHCP-Nachrichten. So können Clients beispielsweise Denial-of-Service-Angriffen durch die Verwendung von gefälschten DHCP-Servern ausgesetzt sein oder schlicht aufgrund unbeabsichtigt aufgesetzter DHCP-Server falsch konfiguriert werden. Netzwerkadministratoren wünschen möglicherweise, die Zuweisung von Adressen auf autorisierte Hosts zu beschränken, um Denial-of-Service- Angriffe in "feindseligen" Umgebungen zu vermeiden, in denen das Netzwermedium nicht physisch gesichert ist, wie etwa drahtlose Netze oder Wohngemeinschaftsunterkünfte von Hochschulen.
Der DHCP-Authentifizierungsmechanismus basiert auf dem Entwurf der Authentifizierung für DHCPv4 [4].
21.1. Sicherheit von zwischen Servern und Relay-Agenten gesendeten Nachrichten
Relay-Agenten und Server, die Nachrichten sicher austauschen, verwenden die IPsec-Mechanismen für IPv6 [7]. Wenn eine Client-Nachricht über mehrere Relay-Agenten weitergeleitet wird, müssen alle Relay-Agenten unabhängige, paarweise Vertrauensbeziehungen aufgebaut 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-Agent 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-Agenten und Server, die eine sichere Kommunikation zwischen Relay-Agent und Server oder zwischen Relay-Agent und Relay-Agent unterstützen, verwenden IPsec unter folgenden Bedingungen:
Selektoren Relay-Agenten werden manuell mit den Adressen der
Relay-Agenten oder Server konfiguriert, an die
DHCP-Nachrichten weitergeleitet werden sollen. Jeder
Relay-Agent und Server, der IPsec zum Absichern von
DHCP-Nachrichten verwenden wird, muss zudem mit einer
Liste der Relay-Agenten konfiguriert werden, an die
Nachrichten zurückgesendet werden. Die Selektoren für
die Relay-Agenten und Server sind die Paare von
Adressen, die Relay-Agenten und Server definieren, die
DHCP-Nachrichten auf den DHCPv6-UDP-Ports 546 und 547
austauschen.
Modus Relay-Agenten und Server verwenden den Transportmodus
und ESP. Die Informationen in DHCP-Nachrichten werden
im Allgemeinen nicht als vertraulich betrachtet, sodass
Verschlüsselung nicht verwendet werden muss (d. h. es
kann NULL-Verschlüsselung verwendet werden).
Schlüsselverwaltung Da die Relay-Agenten und Server innerhalb einer
Organisation verwendet werden, sind Public-Key-Verfahren
nicht notwendig. Da die Relay-Agenten und Server
manuell konfiguriert werden müssen, kann manuell
konfigurierte Schlüsselverwaltung ausreichen, bietet
jedoch keinen Schutz gegen erneut abgespielte
Nachrichten. Entsprechend SOLLTE IKE mit vorab
geteilten Geheimnissen unterstützt werden. IKE mit
Public-Keys KANN unterstützt werden.
Sicherheitsrichtlinie DHCP-Nachrichten zwischen Relay-Agenten und
Servern sollten nur von DHCP-Peers akzeptiert werden,
wie sie in der lokalen Konfiguration identifiziert
sind.
Authentifizierung Gemeinsam verwendete Schlüssel, indiziert nach der
Quell-IP-Adresse der empfangenen DHCP-Nachricht, sind
in dieser Anwendung ausreichend.
Verfügbarkeit Angemessene IPsec-Implementierungen werden
voraussichtlich für Server und für Relay-Agenten in
funktionsreicheren Geräten in Unternehmens- und
Kern-ISP-Netzen verfügbar sein. IPsec ist eher nicht
verfügbar für Relay-Agenten in Einstiegsgeräten, die
primär im Heim- oder Kleinstbüromarkt verwendet werden.
21.2. Zusammenfassung der DHCP-Authentifizierung
Die Authentifizierung von DHCP-Nachrichten erfolgt durch Verwendung der Authentication-Option (siehe Abschnitt 22.11). Die in der Authentication-Option übertragenen 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 stellt einen Rahmen für mehrere Authentifizierungsprotokolle bereit. Hier werden zwei solcher Protokolle definiert. Andere, künftig definierte Protokolle werden in separaten Dokumenten spezifiziert.
Eine DHCP-Nachricht DARF NICHT mehr als eine Authentication-Option enthalten.
Das protocol-Feld in der Authentication-Option identifiziert das spezifische Protokoll, das verwendet wurde, um die in der Option übertragenen Authentifizierungsinformationen zu erzeugen. Das algorithm- Feld identifiziert einen spezifischen Algorithmus innerhalb des Authentifizierungsprotokolls; beispielsweise gibt das algorithm-Feld den Hash-Algorithmus an, der zur Erzeugung des Message Authentication Code (MAC) in der Authentication-Option verwendet wurde. Das Wiedergabeerkennungs-Methode-Feld (RDM) gibt die Art der in dem Feld für Wiedergabeerkennung verwendeten Wiedergabeerkennung an.
21.3. Wiedergabeerkennung (Replay Detection)
Das Replay Detection Method (RDM)-Feld bestimmt die Art der in dem Feld für Wiedergabeerkennung verwendeten Wiedergabeerkennung.
Wenn das RDM-Feld 0x00 enthält, MUSS das Feld für Wiedergabeerkennung auf den Wert eines monoton steigenden Zählers gesetzt werden. Die Verwendung eines Zählerwerts, wie etwa der aktuellen Tageszeit (beispielsweise 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 (Verzögerte Authentifizierung)
Wenn das protocol-Feld 2 ist, verwendet die Nachricht den Mechanismus der "delayed authentication" (verzögerten Authentifizierung). 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 vom Ursprung erzeugten Nonce-Wert als Message Authentication Code (MAC), um Nachrichtenauthentifizierung und Einheitenauthentifizierung bereitzustellen.
Die Verwendung einer bestimmten, auf dem HMAC-Protokoll [8] unter Verwendung des MD5-Hash [16] basierenden Technik 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 seinen Präferenzen aus. Der Client setzt das Feld für Wiedergabeerkennung 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 zur Konstruktion des Inhalts des Authentifizierungsinformationsfelds verwendet wurde. Das RDM-Feld identifiziert die Methode, die zur Konstruktion des Inhalts des Felds für Wiedergabeerkennung verwendet wurde.
Das Format der Authentifizierungsinformation 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 length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCP realm Der DHCP-Bereich, der den Schlüssel identifiziert, der zur
Erzeugung des HMAC-MD5-Werts verwendet wurde.
key ID Der Schlüsselbezeichner, der den Schlüssel identifiziert,
der zur Erzeugung des HMAC-MD5-Werts verwendet wurde.
HMAC-MD5 Der Message Authentication Code, der durch Anwendung von
MD5 auf die DHCP-Nachricht unter Verwendung des durch den
DHCP-Bereich, den Client-DUID und die key ID identifizierten
Schlüssels erzeugt wurde.
Der Sender berechnet den MAC unter Verwendung des HMAC-Erzeugungsalgorithmus [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-Nachrichten-Headers und des Optionsfelds, 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 etwa HMAC-SHA, wird als separates Protokoll
spezifiziert.
Der zur Identifizierung von Authentifizierungsschlüsseln verwendete
DHCP-Bereich wird so gewählt, dass er unter administrativen Domänen
eindeutig ist. Die Verwendung des DHCP-Bereichs erlaubt es
DHCP-Administratoren, Konflikte bei der Verwendung von
Schlüsselbezeichnern zu vermeiden, und erlaubt einem Host, der DHCP
verwendet, authentifiziertes DHCP zu nutzen, während er zwischen
DHCP-administrativen Domänen roamingt.
21.4.2. Nachrichtenvalidierung
Jede DHCP-Nachricht, die mehr als eine Authentication-Option enthält, MUSS verworfen werden.
Um eine eingehende Nachricht zu validieren, prüft der Empfänger zunächst, dass der Wert im Feld für Wiedergabeerkennung gemäß der durch das RDM-Feld spezifizierten Wiedergabeerkennungsmethode 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üsselverwendung
Jeder DHCP-Client besitzt einen Satz von Schlüsseln. Jeder Schlüssel wird durch <DHCP-Bereich, Client-DUID, key id> identifiziert. Jeder Schlüssel besitzt zudem eine Lebensdauer. Der Schlüssel darf über das Ende seiner Lebensdauer hinaus nicht verwendet werden. Die Schlüssel des Clients werden ihm anfänglich über einen Out-of-band-Mechanismus verteilt. Die Lebensdauer für jeden Schlüssel wird mit dem Schlüssel verteilt. Mechanismen für die 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-Berücksichtigungen für das Delayed Authentication Protocol
Der Client kündigt seine Absicht, DHCP-Authentifizierung zu verwenden, durch Aufnahme einer Authentication-Option in seine Solicit-Nachricht an. Der Server wählt einen Schlüssel für den Client basierend auf dem 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, nimmt er eine Authentication-Option mit dem gewünschten protocol, algorithm und RDM auf, wie in Abschnitt 21.4 beschrieben. Der Client nimmt keine Wiedergabeerkennung oder Authentifizierungsinformation in die Authentication-Option auf.
21.4.4.2. Empfang von Advertise-Nachrichten
Der Client validiert alle Advertise-Nachrichten, die eine Authentication-Option enthalten, welche das Delayed Authentication Protocol angibt, unter Verwendung des Validierungstests gemäß Abschnitt 21.4.2.
Das Verhalten des Clients, wenn keine Advertise-Nachrichten Authentifizierungsinformationen enthalten oder den Validierungstest bestehen, wird durch die lokale Richtlinie 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, die lokale Richtlinie so zu setzen, dass nicht authentifizierte Nachrichten akzeptiert werden, sollte mit Sorgfalt getroffen werden. Das Akzeptieren einer nicht authentifizierten Advertise-Nachricht kann den Client für das Vortäuschen von Identitäten (Spoofing) und andere Angriffe anfällig 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 Angriffen über nicht authentifizierte Nachrichten ausgesetzt ist.
Ein Client MUSS so konfigurierbar sein, dass er nicht authentifizierte Nachrichten verwirft, 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 die ersteren akzeptieren und die letzteren verwerfen. Wenn ein Client eine nicht authentifizierte Nachricht akzeptiert, SOLLTE er 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, durch die er den Server ausgewählt hat, MUSS der Client Authentifizierungsinformationen für nachfolgende Request-, Confirm-, Renew-, Rebind- oder Release- Nachrichten, die an den Server gesendet werden, erzeugen, wie in Abschnitt 21.4 beschrieben. Wenn der Client eine nachfolgende Nachricht sendet, MUSS er denselben Schlüssel verwenden, den der Server zur Erzeugung der Authentifizierungsinformationen verwendet hat.
21.4.4.4. Senden von Information-request-Nachrichten
Wenn der Server einen Schlüssel für den Client in einem vorherigen Nachrichtenaustausch 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 erzeugen.
21.4.4.5. Empfang von Reply-Nachrichten
Wenn der Client die Advertise, die er akzeptiert hat, 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 das Validierungsversagen 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 bestand, KANN der Client eine nicht authentifizierte Reply-Nachricht vom Server akzeptieren.
21.4.4.6. Empfang von Reconfigure-Nachrichten
Der Client MUSS die Reconfigure verwerfen, wenn die Nachricht den Validierungstest nicht besteht, und KANN das Validierungsversagen protokollieren.
21.4.5. Server-Berücksichtigungen für das Delayed Authentication Protocol
Nach Empfang einer Solicit-Nachricht, die eine Authentication-Option enthält, wählt der Server einen Schlüssel für den Client, basierend auf dem 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 Client und Server zu validieren.
21.4.5.1. Empfang von Solicit-Nachrichten und Senden von Advertise-Nachrichten
Der Server wählt einen Schlüssel für den Client und nimmt Authentifizierungsinformationen in die an den Client zurückgesendete Advertise-Nachricht auf, wie in Abschnitt 21.4 spezifiziert. Der Server MUSS den Bezeichner 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. Empfang 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, das Validierungsversagen 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 aufnehmen, die unter Verwendung des in der empfangenen Nachricht identifizierten Schlüssels erzeugt wurden, wie in Abschnitt 21.4 spezifiziert.
21.5. Reconfigure Key Authentication Protocol
Das Reconfigure Key Authentication Protocol bietet Schutz gegen eine 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 für die Verwendung bei der Authentifizierung nachfolgender Reconfigure-Nachrichten von diesem Server auf. Der Server schließt dann einen HMAC, der aus dem Reconfigure Key berechnet wurde, in nachfolgende Reconfigure-Nachrichten ein.
Sowohl der vom Server an den Client gesendete Reconfigure Key als auch der 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 Client und 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 | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Typ der Daten im Value-Feld dieser Option:
1 Reconfigure Key-Wert (verwendet in Reply-Nachricht).
2 HMAC-MD5-Digest der Nachricht (verwendet in
Reconfigure-Nachricht).
Value Daten wie durch das Feld definiert.
21.5.2. Server-Berücksichtigungen 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 Bit lang und MUSS eine kryptografisch starke Zufalls- oder Pseudozufallszahl sein, die nicht leicht vorhersehbar ist.
Um eine Reconfigure-Nachricht zu authentifizieren, wählt der Server einen Wiedergabeerkennungswert gemäß dem vom Server ausgewählten RDM und berechnet einen HMAC-MD5 der Reconfigure-Nachricht unter Verwendung des Reconfigure Keys für den Client. Der Server berechnet den 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 nimmt den HMAC-MD5 in das Authentifizierungsinformationsfeld einer Authentication-Option auf, die in die an den Client gesendete Reconfigure-Nachricht eingeschlossen wird.
21.5.3. Client-Berücksichtigungen 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 für die Verwendung bei der Authentifizierung nachfolgender Reconfigure- Nachrichten auf.
Um eine Reconfigure-Nachricht zu authentifizieren, berechnet der Client einen HMAC-MD5 über die DHCP-Reconfigure-Nachricht unter Verwendung des vom Server empfangenen Reconfigure Keys. Wenn dieser berechnete HMAC-MD5 mit dem Wert in der Authentication-Option übereinstimmt, akzeptiert der Client die Reconfigure-Nachricht.