20. Authentifizierung von DHCP-Nachrichten
Dieser Abschnitt bewahrt den RFC-Text zu DHCPv6, einschliesslich Nachrichtenaustausch, Relay-Verhalten, DUIDs, IA_NA, IA_TA, IA_PD, DHCP-Optionen, RKAP-Authentifizierung, IANA-Registern, normativen Anforderungen und der Optionsvorkommensmatrizen im Anhang.
Originaler RFC-Text
20. Authentifizierung von DHCP-Nachrichten
Dieses Dokument definiert zwei Sicherheitsmechanismen fuer die
Authentifizierung von DHCP-Nachrichten: (1) Authentifizierung (und
Verschluesselung) von Nachrichten, die zwischen Servern und Relay
Agents unter Verwendung von IPsec gesendet werden, und (2) Schutz
gegen Fehlkonfiguration eines Clients, die durch eine von einem
boesartigen DHCP-Server gesendete Reconfigure-Nachricht verursacht
wird.
20.1. Sicherheit von Nachrichten zwischen Servern und Relay Agents
Relay Agents und Server, die Nachrichten austauschen, koennen IPsec wie
in [RFC8213] beschrieben verwenden.
20.2. Zusammenfassung der DHCP-Authentifizierung
Die Authentifizierung von DHCP-Nachrichten erfolgt durch Verwendung der
Authentication option (siehe Section 21.11). Die in der
Authentication option transportierten Authentifizierungsinformationen
koennen verwendet werden, um die Quelle einer DHCP-Nachricht
zuverlaessig zu identifizieren und zu bestaetigen, dass der Inhalt der
DHCP-Nachricht nicht manipuliert wurde.
Die Authentication option stellt ein Framework fuer mehrere
Authentifizierungsprotokolle bereit. Ein solches Protokoll, RKAP, ist
in Section 20.4 definiert. Andere zukuenftig definierte Protokolle
werden in separaten Dokumenten spezifiziert.
Jede DHCP-Nachricht MUST NOT mehr als eine Authentication option
enthalten.
Das Feld protocol in der Authentication option identifiziert das
spezifische Protokoll, das zur Erzeugung der in der Option
transportierten Authentifizierungsinformationen verwendet wird. Das
Feld algorithm identifiziert einen spezifischen Algorithmus innerhalb
des Authentifizierungsprotokolls; beispielsweise gibt das Feld
algorithm den Hash-Algorithmus an, der zur Erzeugung des Message
Authentication Code (MAC) in der Authentication option verwendet wird.
Das Feld RDM gibt die Art der Replay Detection an, die im Feld replay
detection verwendet wird.
20.3. Replay Detection
Das Feld RDM der Authentication option (siehe Section 21.11) bestimmt
die Art der Replay Detection, die im Feld replay detection verwendet
wird.
Wenn das Feld RDM 0x00 enthaelt, MUST das Feld replay detection auf den
Wert einer streng monoton steigenden vorzeichenlosen 64-Bit-Ganzzahl
(modulo 2^64) gesetzt werden. Die Verwendung dieser Technik kann die
Gefahr von Replay-Angriffen verringern. Diese Methode MUST von allen
Authentication-option-Protokollen unterstuetzt werden. Eine
Moeglichkeit waere die Verwendung des 64-Bit-NTP-Timestamp-Formats
[RFC5905]).
Ein Client, der eine Nachricht mit auf 0x00 gesetztem RDM-Feld
empfaengt, MUST sein Feld replay detection mit dem vorherigen Wert
vergleichen, der von demselben Server gesendet wurde (basierend auf der
Server Identifier option; siehe Section 21.3), und die Nachricht nur
akzeptieren, wenn der empfangene Wert groesser ist, und diesen als
neuen Wert speichern. Wenn ein Client zum ersten Mal eine von einem
Server gesendete Authentication option verarbeitet, MUST der Client den
replay-detection-Wert speichern und die Replay-Detection-Pruefung
ueberspringen.
Server, die den reconfigure-Mechanismus unterstuetzen, MUST
sicherstellen, dass der replay-detection-Wert zwischen Neustarts
erhalten bleibt. Andernfalls koennen Clients vom Server gesendete
Reconfigure-Nachrichten ablehnen, wodurch der reconfigure-Mechanismus
effektiv nutzlos wird.
20.4. Reconfiguration Key Authentication Protocol (RKAP)
RKAP bietet Schutz gegen Fehlkonfiguration eines Clients, die durch
eine von einem boesartigen DHCP-Server gesendete Reconfigure-Nachricht
verursacht wird. In diesem Protokoll sendet ein DHCP-Server dem Client
im initialen Austausch von DHCP-Nachrichten einen reconfigure key. Der
Client speichert den reconfigure key, um nachfolgende
Reconfigure-Nachrichten von diesem Server zu authentifizieren. Der
Server nimmt dann in nachfolgende Reconfigure-Nachrichten einen Hashed
Message Authentication Code (HMAC) auf, der aus dem reconfigure key
berechnet wurde.
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 (siehe
Section 21.11) transportiert. Das Format der
Authentifizierungsinformationen ist im folgenden Abschnitt definiert.
RKAP wird (vom Server initiiert) nur verwendet, wenn Client und Server
die Verwendung von Reconfigure-Nachrichten ausgehandelt haben.
20.4.1. Verwendung der Authentication option in RKAP
Die folgenden Felder werden in einer Authentication option (siehe
Section 21.11) fuer RKAP gesetzt:
* protocol: 3
* algorithm: 1
* RDM: 0
The format of the authentication information for RKAP is:
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) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 11: RKAP-Authentifizierungsinformationen
Type: Datentyp im Feld Value, der in dieser Option transportiert wird:
1 Reconfigure-key-Wert (verwendet in der Reply-Nachricht).
2 HMAC-MD5-Digest der Nachricht (verwendet in der
Reconfigure-Nachricht).
Ein 1-Oktett-Feld.
Value: Daten wie durch das Feld Type definiert. Ein 16-Oktett-Feld.
20.4.2. Serverueberlegungen fuer RKAP
Der Server waehlt waehrend des Request/Reply-, Solicit/Reply- oder
Information-request/Reply-Nachrichtenaustauschs einen reconfigure key
fuer einen Client aus. Der Server speichert den reconfigure key und
uebertraegt diesen Schluessel in der Reply-Nachricht in einer
Authentication option (siehe Section 21.11) an den Client.
Der reconfigure key ist 128 Bits lang und MUST eine kryptographisch
starke Zufalls- oder Pseudozufallszahl sein, die nicht leicht
vorhergesagt werden kann.
Um eine Reconfigure-Nachricht zu authentifizieren, waehlt der Server
einen replay-detection-Wert gemaess dem vom Server ausgewaehlten RDM
und berechnet ein HMAC-MD5 der Reconfigure-Nachricht unter Verwendung
des reconfigure key fuer den Client. Der Server berechnet das HMAC-MD5
ueber die gesamte DHCP-Reconfigure-Nachricht einschliesslich der
Authentication option; das HMAC-MD5-Feld in der Authentication option
wird fuer die HMAC-MD5-Berechnung auf 0 gesetzt. Der Server nimmt das
HMAC-MD5 in das Feld authentication information einer Authentication
option auf, die in der an den Client gesendeten Reconfigure-Nachricht
enthalten ist.
20.4.3. Clientueberlegungen fuer RKAP
Der Client erhaelt vom Server in der initialen Reply-Nachricht eine
reconfigure key in einer Authentication option (siehe Section 21.11).
Der Client speichert den reconfigure key zur Authentifizierung
nachfolgender Reconfigure-Nachrichten.
Um eine Reconfigure-Nachricht zu authentifizieren, berechnet der Client
ein HMAC-MD5 ueber die Reconfigure-Nachricht, wobei fuer das
HMAC-MD5-Feld Nullen eingesetzt werden, unter Verwendung des vom Server
empfangenen reconfigure key. Wenn dieses berechnete HMAC-MD5 mit dem
Wert in der Authentication option uebereinstimmt, akzeptiert der Client
die Reconfigure-Nachricht.