21. Authentication of DHCP Messages (Authentification des messages DHCP)

21. Authentication of DHCP Messages (Authentification des messages DHCP)

Certains administrateurs réseau peuvent souhaiter fournir l'authentification de la source et du contenu des messages DHCP. Par exemple, les clients peuvent être victimes d'attaques par déni de service via l'utilisation de serveurs DHCP factices, ou peuvent simplement être mal configurés en raison de serveurs DHCP instanciés involontairement. Les administrateurs réseau peuvent souhaiter contraindre l'attribution d'adresses aux hôtes autorisés pour éviter les attaques par déni de service dans des environnements « hostiles » où le moyen réseau n'est pas physiquement sécurisé, tels que les réseaux sans fil ou les résidences universitaires.

Le mécanisme d'authentification DHCP est basé sur la conception de l'authentification pour DHCPv4 [4].

21.1. Security of Messages Sent Between Servers and Relay Agents (Sécurité des messages échangés entre serveurs et agents de relais)

Les agents de relais et les serveurs échangeant des messages de manière sécurisée utilisent les mécanismes IPsec pour IPv6 [7]. Si un message client est relayé via plusieurs agents de relais, chacun des agents de relais doit avoir établi des relations de confiance indépendantes et par paires. C'est-à-dire que si les messages du client C seront relayés par l'agent de relais A à l'agent de relais B puis au serveur, les agents de relais A et B doivent être configurés pour utiliser IPSec pour les messages qu'ils échangent, et l'agent de relais B et le serveur doivent être configurés pour utiliser IPSec pour les messages qu'ils échangent.

Les agents de relais et les serveurs prenant en charge la communication sécurisée agent de relais-serveur ou agent de relais-agent de relais utilisent IPsec dans les conditions suivantes :

Aspect	Description
Selectors	Les agents de relais sont configurés manuellement avec les adresses de l'agent de relais ou du serveur vers lesquels relayer les messages DHCP. Chaque agent de relais et serveur qui utilisera IPsec pour protéger les messages DHCP doit également être configuré avec une liste des agents de relais auxquels les messages seront renvoyés. Les sélecteurs pour les agents de relais et les serveurs seront les paires d'adresses qui définissent les agents de relais et serveurs échangeant des messages DHCP sur les ports UDP DHCPv6 546 et 547.
Mode	Les agents de relais et les serveurs utilisent le mode transport et ESP. Les informations dans les messages DHCP ne sont généralement pas considérées comme confidentielles, donc le chiffrement ne doit pas être utilisé (c'est-à-dire que le chiffrement NULL peut être utilisé).
Key management	Étant donné que les agents de relais et les serveurs sont utilisés au sein d'une organisation, les schémas à clé publique ne sont pas nécessaires. Étant donné que les agents de relais et les serveurs doivent être configurés manuellement, la gestion de clés configurée manuellement peut suffire, mais ne fournit pas de défense contre les messages rejoués. Par conséquent, IKE avec secrets pré-partagés DEVRAIT être pris en charge. IKE avec clés publiques PEUT être pris en charge.
Security policy	Les messages DHCP entre agents de relais et serveurs ne devraient être acceptés que des pairs DHCP tels qu'identifiés dans la configuration locale.
Authentication	Des clés partagées, indexées sur l'adresse IP source du message DHCP reçu, sont adéquates dans cette application.
Availability	Des implémentations IPsec appropriées seront probablement disponibles pour les serveurs et pour les agents de relais dans les périphériques plus riches utilisés dans les réseaux d'entreprise et les cœurs ISP. IPsec est moins susceptible d'être disponible pour les agents de relais dans les périphériques bas de gamme utilisés principalement sur les marchés domestiques ou des petites entreprises.

21.2. Summary of DHCP Authentication (Résumé de l'authentification DHCP)

L'authentification des messages DHCP est réalisée via l'utilisation de l'option Authentication (voir section 22.11). Les informations d'authentification transportées dans l'option Authentication peuvent être utilisées pour identifier de manière fiable la source d'un message DHCP et pour confirmer que le contenu du message DHCP n'a pas été altéré.

L'option Authentication fournit un cadre pour plusieurs protocoles d'authentification. Deux de ces protocoles sont définis ici. D'autres protocoles définis à l'avenir seront spécifiés dans des documents séparés.

Chaque message DHCP NE DOIT PAS inclure plus d'une option Authentication.

Le champ protocol dans l'option Authentication identifie le protocole spécifique utilisé pour générer les informations d'authentification transportées dans l'option. Le champ algorithm identifie un algorithme spécifique au sein du protocole d'authentification ; par exemple, le champ algorithm spécifie l'algorithme de hachage utilisé pour générer le message authentication code (MAC) dans l'option d'authentification. Le champ du mécanisme de détection de rejeu (RDM) spécifie le type de détection de rejeu utilisé dans le champ de détection de rejeu.

21.3. Replay Detection (Détection de rejeu)

Le champ Replay Detection Method (RDM) détermine le type de détection de rejeu utilisé dans le champ Replay Detection.

Si le champ RDM contient 0x00, le champ de détection de rejeu DOIT être défini sur la valeur d'un compteur à incrémentation monotone. L'utilisation d'une valeur de compteur, telle que l'heure actuelle du jour (par exemple, un timestamp au format NTP [9]), peut réduire le danger des attaques par rejeu. Cette méthode DOIT être prise en charge par tous les protocoles.

21.4. Delayed Authentication Protocol (Protocole d'authentification retardée)

Si le champ protocol est 2, le message utilise le mécanisme d'« authentification retardée » (Delayed Authentication). Dans l'authentification retardée, le client demande l'authentification dans son message Solicit, et le serveur répond avec un message Advertise incluant des informations d'authentification. Ces informations d'authentification contiennent une valeur nonce générée par la source comme message authentication code (MAC) pour fournir l'authentification du message et l'authentification de l'entité.

L'utilisation d'une technique particulière basée sur le protocole HMAC [8] utilisant le hachage MD5 [16] est définie ici.

21.4.1. Use of the Authentication Option in the Delayed Authentication Protocol (Utilisation de l'option Authentication dans le protocole d'authentification retardée)

Dans un message Solicit, le client remplit les champs protocol, algorithm et RDM dans l'option Authentication avec les préférences du client. Le client définit le champ de détection de rejeu à zéro et omet le champ des informations d'authentification. Le client définit le champ option-len à 11.

Dans tous les autres messages, les champs protocol et algorithm identifient la méthode utilisée pour construire le contenu du champ des informations d'authentification. Le champ RDM identifie la méthode utilisée pour construire le contenu du champ de détection de rejeu.

Le format des informations d'authentification est :

 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 — Le DHCP realm qui identifie la clé utilisée pour générer la valeur HMAC-MD5.
• key ID — L'identifiant de clé qui a identifié la clé utilisée pour générer la valeur HMAC-MD5.
• HMAC-MD5 — Le message authentication code généré en appliquant MD5 au message DHCP en utilisant la clé identifiée par le DHCP realm, le DUID du client et le key ID.

L'émetteur calcule le MAC en utilisant l'algorithme de génération HMAC [8] et la fonction de hachage MD5 [16]. Le message DHCP entier (en définissant le champ MAC de l'option d'authentification à zéro), y compris l'en-tête du message DHCP et le champ des options, est utilisé comme entrée à la fonction de calcul HMAC-MD5.

DISCUSSION :

L'Algorithme 1 spécifie l'utilisation de HMAC-MD5. L'utilisation d'une technique différente, telle que HMAC-SHA, sera spécifiée comme protocole séparé.

Le DHCP realm utilisé pour identifier les clés d'authentification est choisi pour être unique entre les domaines administratifs. L'utilisation du DHCP realm permet aux administrateurs DHCP d'éviter les conflits dans l'utilisation des identifiants de clé, et permet à un hôte utilisant DHCP de utiliser DHCP authentifié tout en se déplaçant entre domaines administratifs DHCP.

21.4.2. Validation of Messages (Validation des messages)

Chaque message DHCP qui inclut plus d'une option d'authentification DOIT être ignoré.

Pour valider un message entrant, le récepteur vérifie d'abord que la valeur dans le champ de détection de rejeu est acceptable selon la méthode de détection de rejeu spécifiée par le champ RDM. Ensuite, le récepteur calcule le MAC comme décrit dans [8]. Le message DHCP entier (en définissant le champ MAC de l'option d'authentification à 0) est utilisé comme entrée à la fonction de calcul HMAC-MD5. Si le MAC calculé par le récepteur ne correspond pas au MAC contenu dans l'option d'authentification, le récepteur DOIT ignorer le message DHCP.

21.4.3. Use of Keys (Utilisation des clés)

Chaque client DHCP possède un ensemble de clés. Chaque clé est identifiée par <DHCP realm, DUID client, key id>. Chaque clé a également une durée de vie. La clé ne peut pas être utilisée au-delà de la fin de sa durée de vie. Les clés du client sont initialement distribuées au client via un mécanisme out-of-band. La durée de vie de chaque clé est distribuée avec la clé. Les mécanismes de distribution des clés et de spécification de la durée de vie sont hors du champ d'application de ce document.

Le client et le serveur utilisent l'une des clés du client pour authentifier les messages DHCP au cours d'une session (jusqu'au prochain message Solicit envoyé par le client).

21.4.4. Client Considerations for the Delayed Authentication Protocol (Considérations client pour le protocole d'authentification retardée)

Le client annonce son intention d'utiliser l'authentification DHCP en incluant une option Authentication dans son message Solicit. Le serveur sélectionne une clé pour le client basée sur le DUID du client. Le client et le serveur utilisent cette clé pour authentifier tous les messages DHCP échangés au cours de la session.

21.4.4.1. Sending Solicit Messages (Envoi de messages Solicit)

Lorsque le client envoie un message Solicit et souhaite utiliser l'authentification, il inclut une option Authentication avec le protocol, algorithm et RDM souhaités comme décrit dans la section 21.4. Le client n'inclut aucune détection de rejeu ou information d'authentification dans l'option Authentication.

21.4.4.2. Receipt of Advertise Messages (Réception de messages Advertise)

Le client valide tous les messages Advertise contenant une option Authentication qui spécifie le protocole d'authentification retardée en utilisant le test de validation décrit dans la section 21.4.2.

Le comportement du client, si aucun message Advertise n'inclut d'informations d'authentification ou ne réussit pas le test de validation, est contrôlé par la politique locale sur le client. Selon la politique du client, le client PEUT choisir de répondre à un message Advertise qui n'a pas été authentifié.

La décision de définir la politique locale pour accepter des messages non authentifiés doit être prise avec prudence. Accepter un message Advertise non authentifié peut rendre le client vulnérable à l'usurpation et à d'autres attaques. Si les utilisateurs locaux ne sont pas explicitement informés que le client a accepté un message Advertise non authentifié, les utilisateurs peuvent supposer à tort que le client a reçu une adresse authentifiée et n'est pas soumis à des attaques DHCP via des messages non authentifiés.

Un client DOIT être configurable pour ignorer les messages non authentifiés, et DEVRAIT être configuré par défaut pour ignorer les messages non authentifiés si le client a été configuré avec une clé d'authentification ou d'autres informations d'authentification. Un client PEUT choisir de différencier les messages Advertise sans informations d'authentification et les messages Advertise qui ne réussissent pas le test de validation ; par exemple, un client pourrait accepter les premiers et ignorer les seconds. Si un client accepte un message non authentifié, le client DEVRAIT informer les utilisateurs locaux et DEVRAIT enregistrer l'événement.

21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release Messages (Envoi de messages Request, Confirm, Renew, Rebind, Decline ou Release)

Si le client a authentifié le message Advertise via lequel le client a sélectionné le serveur, le client DOIT générer des informations d'authentification pour les messages Request, Confirm, Renew, Rebind ou Release ultérieurs envoyés au serveur, comme décrit dans la section 21.4. Lorsque le client envoie un message ultérieur, il DOIT utiliser la même clé que celle utilisée par le serveur pour générer les informations d'authentification.

21.4.4.4. Sending Information-request Messages (Envoi de messages Information-request)

Si le serveur a sélectionné une clé pour le client dans un échange de messages précédent (voir section 21.4.5.1), le client DOIT utiliser la même clé pour générer les informations d'authentification pour toute la session.

21.4.4.5. Receipt of Reply Messages (Réception de messages Reply)

Si le client a authentifié le message Advertise qu'il a accepté, le client DOIT valider le message Reply associé du serveur. Le client DOIT ignorer le Reply si le message ne réussit pas le test de validation et PEUT enregistrer l'échec de la validation. Si le Reply ne réussit pas le test de validation, le client DOIT redémarrer le processus de configuration DHCP en envoyant un message Solicit.

Si le client a accepté un message Advertise qui n'incluait pas d'informations d'authentification ou ne réussissait pas le test de validation, le client PEUT accepter un message Reply non authentifié du serveur.

21.4.4.6. Receipt of Reconfigure Messages (Réception de messages Reconfigure)

Le client DOIT ignorer le Reconfigure si le message ne réussit pas le test de validation et PEUT enregistrer l'échec de la validation.

21.4.5. Server Considerations for the Delayed Authentication Protocol (Considérations serveur pour le protocole d'authentification retardée)

Après avoir reçu un message Solicit contenant une option Authentication, le serveur sélectionne une clé pour le client, basée sur le DUID du client et sur les politiques de sélection de clé avec lesquelles le serveur est configuré. Le serveur identifie la clé sélectionnée dans le message Advertise et l'utilise pour valider les messages ultérieurs entre le client et le serveur.

21.4.5.1. Receipt of Solicit and Sending of Advertise (Réception de Solicit et envoi d'Advertise)

Le serveur sélectionne une clé pour le client et inclut des informations d'authentification dans le message Advertise renvoyé au client comme spécifié dans la section 21.4. Le serveur DOIT enregistrer l'identifiant de la clé sélectionnée pour le client et utiliser cette même clé pour valider les messages ultérieurs avec le client.

21.4.5.2. Receipt of Request, Confirm, Renew, Rebind or Release and Sending of Reply (Réception de Request, Confirm, Renew, Rebind ou Release et envoi de Reply)

Le serveur utilise la clé identifiée dans le message et valide le message comme spécifié dans la section 21.4.2. Si le message ne réussit pas le test de validation ou si le serveur ne connaît pas la clé identifiée par le champ « key ID », le serveur DOIT ignorer le message et PEUT choisir d'enregistrer l'échec de la validation.

Si le message réussit le test de validation, le serveur répond au message spécifique comme décrit dans la section 18.2. Le serveur DOIT inclure des informations d'authentification générées en utilisant la clé identifiée dans le message reçu, comme spécifié dans la section 21.4.

21.5. Reconfigure Key Authentication Protocol (Protocole d'authentification par clé Reconfigure)

Le protocole d'authentification par clé Reconfigure fournit une protection contre la mauvaise configuration d'un client causée par un message Reconfigure envoyé par un serveur DHCP malveillant. Dans ce protocole, un serveur DHCP envoie une Reconfigure Key au client dans l'échange initial de messages DHCP. Le client enregistre la Reconfigure Key pour l'utiliser dans l'authentification des messages Reconfigure ultérieurs de ce serveur. Le serveur inclut ensuite un HMAC calculé à partir de la Reconfigure Key dans les messages Reconfigure ultérieurs.

La Reconfigure Key envoyée par le serveur au client et le HMAC dans les messages Reconfigure ultérieurs sont tous deux transportés comme informations d'authentification dans une option Authentication. Le format des informations d'authentification est défini dans la section suivante.

Le protocole de clé Reconfigure est utilisé (initié par le serveur) uniquement si le client et le serveur n'utilisent aucun autre protocole d'authentification et que le client et le serveur ont négocié l'utilisation de messages Reconfigure.

21.5.1. Use of the Authentication Option in the Reconfigure Key Authentication Protocol (Utilisation de l'option Authentication dans le protocole d'authentification par clé Reconfigure)

Les champs suivants sont définis dans une option Authentication pour le protocole d'authentification par clé Reconfigure :

• protocol — 3
• algorithm — 1
• RDM — 0

Le format des informations d'authentification pour le protocole d'authentification par clé Reconfigure est :

 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 — Type de données dans le champ Value transporté dans cette option :
  • 1 — Valeur de la Reconfigure Key (utilisée dans le message Reply).
  • 2 — Digest HMAC-MD5 du message (utilisé dans le message Reconfigure).
• Value — Données telles que définies par le champ.

21.5.2. Server Considerations for the Reconfigure Key Authentication Protocol (Considérations serveur pour le protocole de clé Reconfigure)

Le serveur sélectionne une Reconfigure Key pour un client lors de l'échange de messages Request/Reply, Solicit/Reply ou Information-request/Reply. Le serveur enregistre la Reconfigure Key et la transmet au client dans une option Authentication dans le message Reply.

La Reconfigure Key a une longueur de 128 bits, et DOIT être un nombre aléatoire ou pseudo-aléatoire cryptographiquement fort qui ne peut pas être facilement prédit.

Pour fournir l'authentification pour un message Reconfigure, le serveur sélectionne une valeur de détection de rejeu selon l'RDM sélectionné par le serveur, et calcule un HMAC-MD5 du message Reconfigure en utilisant la Reconfigure Key pour le client. Le serveur calcule le HMAC-MD5 sur le message DHCP Reconfigure entier, y compris l'option Authentication ; le champ HMAC-MD5 dans l'option Authentication est défini à zéro pour le calcul HMAC-MD5. Le serveur inclut le HMAC-MD5 dans le champ des informations d'authentification dans une option Authentication incluse dans le message Reconfigure envoyé au client.

21.5.3. Client Considerations for the Reconfigure Key Authentication Protocol (Considérations client pour le protocole de clé Reconfigure)

Le client recevra une Reconfigure Key du serveur dans le message Reply initial du serveur. Le client enregistre la Reconfigure Key pour l'utiliser dans l'authentification des messages Reconfigure ultérieurs.

Pour authentifier un message Reconfigure, le client calcule un HMAC-MD5 sur le message DHCP Reconfigure, en utilisant la Reconfigure Key reçue du serveur. Si ce HMAC-MD5 calculé correspond à la valeur dans l'option Authentication, le client accepte le message Reconfigure.