20. Authentification des messages DHCP
Cette section conserve le texte de la RFC relatif a DHCPv6, notamment les echanges de messages, le comportement des relais, les DUID, IA_NA, IA_TA, IA_PD, les options DHCP, l'authentification RKAP, les registres IANA, les exigences normatives et les matrices d'apparition des options en annexe.
Texte original de la RFC
20. Authentification des messages DHCP
Ce document definit deux mecanismes de securite pour l'authentification
des messages DHCP: (1) l'authentification (et le chiffrement) des
messages envoyes entre les serveurs et les agents relais au moyen
d'IPsec et (2) la protection contre une mauvaise configuration d'un
client provoquee par un message Reconfigure envoye par un serveur DHCP
malveillant.
20.1. Securite des messages envoyes entre serveurs et agents relais
Les agents relais et les serveurs qui echangent des messages peuvent
utiliser IPsec comme detaille dans [RFC8213].
20.2. Resume de l'authentification DHCP
L'authentification des messages DHCP est realisee au moyen de l'option
Authentication (voir Section 21.11). Les informations
d'authentification transportees dans l'option Authentication peuvent
etre utilisees pour identifier de facon fiable la source d'un message
DHCP et confirmer que le contenu du message DHCP n'a pas ete altere.
L'option Authentication fournit un cadre pour plusieurs protocoles
d'authentification. Un tel protocole, RKAP, est defini dans la
Section 20.4. Les autres protocoles definis a l'avenir seront
specifies dans des documents separes.
Tout message DHCP MUST NOT inclure plus d'une option Authentication.
Le champ protocol de l'option Authentication identifie le protocole
specifique utilise pour generer les informations d'authentification
transportees dans l'option. Le champ algorithm identifie un algorithme
specifique au sein du protocole d'authentification; par exemple, le
champ algorithm specifie l'algorithme de hachage utilise pour generer
le Message Authentication Code (MAC) dans l'option Authentication. Le
champ RDM specifie le type de detection de rejeu utilise dans le champ
replay detection.
20.3. Detection de rejeu
Le champ RDM de l'option Authentication (voir Section 21.11) determine
le type de detection de rejeu utilise dans le champ replay detection.
Si le champ RDM contient 0x00, le champ replay detection MUST etre
defini a la valeur d'un entier non signe de 64 bits strictement
monotone croissant (modulo 2^64). L'utilisation de cette technique
peut reduire le risque d'attaques par rejeu. Cette methode MUST etre
prise en charge par tous les protocoles de l'option Authentication. Un
choix possible serait d'utiliser le format de timestamp NTP 64 bits
[RFC5905]).
Un client qui recoit un message dont le champ RDM est defini a 0x00
MUST comparer son champ replay detection avec la valeur precedente
envoyee par ce meme serveur (sur la base de l'option Server Identifier;
voir Section 21.3) et n'accepter le message que si la valeur recue est
superieure, puis l'enregistrer comme nouvelle valeur. Si c'est la
premiere fois qu'un client traite une option Authentication envoyee par
un serveur, le client MUST enregistrer la valeur replay detection et
ignorer le controle de detection de rejeu.
Les serveurs qui prennent en charge le mecanisme reconfigure MUST
s'assurer que la valeur replay detection est conservee entre les
redemarrages. Ne pas le faire peut amener les clients a refuser les
messages Reconfigure envoyes par le serveur, rendant effectivement le
mecanisme reconfigure inutile.
20.4. Reconfiguration Key Authentication Protocol (RKAP)
RKAP fournit une protection contre une mauvaise configuration d'un
client provoquee par un message Reconfigure envoye par un serveur DHCP
malveillant. Dans ce protocole, un serveur DHCP envoie une reconfigure
key au client lors de l'echange initial de messages DHCP. Le client
enregistre la reconfigure key pour l'utiliser dans l'authentification
des messages Reconfigure subsequents provenant de ce serveur. Le
serveur inclut ensuite, dans les messages Reconfigure subsequents, un
Hashed Message Authentication Code (HMAC) calcule a partir de la
reconfigure key.
La reconfigure key envoyee par le serveur au client et le HMAC dans les
messages Reconfigure subsequents sont tous deux transportes comme
informations d'authentification dans une option Authentication (voir
Section 21.11). Le format des informations d'authentification est
defini dans la section suivante.
RKAP est utilise (initie par le serveur) uniquement si le client et le
serveur ont negocie l'utilisation des messages Reconfigure.
20.4.1. Utilisation de l'option Authentication dans RKAP
Les champs suivants sont definis dans une option Authentication (voir
Section 21.11) pour RKAP:
* 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) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Informations d'authentification RKAP
Type: Type des donnees dans le champ Value transporte dans cette
option:
1 Valeur de reconfigure key (utilisee dans le message Reply).
2 Condense HMAC-MD5 du message (utilise dans le message
Reconfigure).
Un champ de 1 octet.
Value: Donnees telles que definies par le champ Type. Un champ de
16 octets.
20.4.2. Considerations relatives au serveur pour RKAP
Le serveur selectionne une reconfigure key pour un client pendant
l'echange de messages Request/Reply, Solicit/Reply ou
Information-request/Reply. Le serveur enregistre la reconfigure key et
transmet cette cle au client dans une option Authentication (voir
Section 21.11) du message Reply.
La reconfigure key a une longueur de 128 bits et MUST etre un nombre
aleatoire ou pseudo-aleatoire cryptographiquement fort, difficilement
previsible.
Pour fournir l'authentification d'un message Reconfigure, le serveur
selectionne une valeur replay detection selon le RDM selectionne par le
serveur et calcule un HMAC-MD5 du message Reconfigure en utilisant la
reconfigure key du client. Le serveur calcule le HMAC-MD5 sur
l'ensemble du message DHCP Reconfigure, y compris l'option
Authentication; le champ HMAC-MD5 dans l'option Authentication est
defini a 0 pour le calcul HMAC-MD5. Le serveur inclut le HMAC-MD5 dans
le champ authentication information d'une option Authentication incluse
dans le message Reconfigure envoye au client.
20.4.3. Considerations relatives au client pour RKAP
Le client recevra une reconfigure key du serveur dans une option
Authentication (voir Section 21.11) du message Reply initial du
serveur. Le client enregistre la reconfigure key pour l'utiliser dans
l'authentification des messages Reconfigure subsequents.
Pour authentifier un message Reconfigure, le client calcule un HMAC-
MD5 sur le message Reconfigure, avec des zeros substitues au champ
HMAC-MD5, en utilisant la reconfigure key recue du serveur. Si ce
HMAC-MD5 calcule correspond a la valeur dans l'option Authentication,
le client accepte le message Reconfigure.