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 soumis à des attaques de déni de service via l'utilisation de serveurs DHCP frauduleux, ou peuvent simplement être mal configurés en raison de serveurs DHCP instanciés par accident. Les administrateurs réseau peuvent souhaiter limiter l'assignation d'adresses aux hôtes autorisés pour éviter des attaques de déni de service dans des environnements "hostiles" (tels que les réseaux sans fil ou les dortoirs universitaires), où le support réseau est physiquement non sécurisé.

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

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

Les agents relais et serveurs qui échangent des messages de manière sécurisée utilisent le mécanisme IPsec d'IPv6 [7]. Si un message client est relayé via plusieurs agents relais, chaque agent relais doit établir une relation de confiance indépendante et appariée. C'est-à-dire que si un message du client C sera relayé par l'agent relais A à l'agent relais B, puis au serveur, l'agent relais A et B doivent être configurés pour utiliser IPSec pour échanger des messages, et l'agent relais B et le serveur doivent être configurés pour utiliser IPSec pour échanger des messages.

Les agents relais et serveurs qui supportent la communication sécurisée agent relais-serveur ou agent relais-agent relais utilisent IPsec sous les conditions suivantes:

Selectors (Sélecteurs)
L'agent relais configure manuellement les adresses des agents relais ou serveurs vers lesquels les messages DHCP seront transférés. Chaque agent relais et serveur qui utilisera IPsec pour protéger les messages DHCP doit également configurer une liste des agents relais vers lesquels les messages seront retournés. Les sélecteurs pour les agents relais et serveurs seront des paires d'adresses définissant les agents relais et serveurs qui échangent des messages DHCP sur les ports UDP DHCPv6 546 et 547.

Mode
Les agents relais et 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 l'utilisation du chiffrement n'est pas nécessaire (c'est-à-dire que le chiffrement NULL peut être utilisé).

Key management (Gestion des clés)
Comme les agents relais et serveurs sont utilisés au sein d'une organisation, un schéma de clé publique n'est pas nécessaire. Comme les agents relais et serveurs doivent être configurés manuellement, la gestion de clé configurée manuellement peut être suffisante, mais ne fournit pas de défense contre les messages rejoués. Par conséquent, IKE utilisant des clés pré-partagées devrait être supporté. IKE utilisant des clés publiques peut être supporté.

Security policy (Politique de sécurité)
Les messages DHCP entre les agents relais et serveurs ne devraient accepter que des messages provenant de pairs DHCP identifiés dans la configuration locale.

Authentication (Authentification)
Une clé partagée indexée à l'adresse IP source du message DHCP reçu est suffisante dans cette application.

Availability (Disponibilité)
Des implémentations IPsec appropriées peuvent être disponibles pour les serveurs et les agents relais dans des dispositifs plus riches en fonctionnalités utilisés pour les réseaux ISP d'entreprise et de cœur. IPsec est peu susceptible d'être disponible pour les agents relais dans des dispositifs bas de gamme principalement destinés au marché domestique ou aux petits bureaux.

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

L'authentification des messages DHCP est accomplie en utilisant 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 d'un 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.

Aucun message DHCP ne doit contenir plusieurs options 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 l'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 code d'authentification de message (MAC) dans l'option Authentication. Le champ Replay Detection Method (RDM) spécifie le type de détection de rejeu utilisé dans le champ replay detection.

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 replay detection doit être défini à la valeur d'un compteur monotone croissant. L'utilisation d'une valeur de compteur (par exemple, l'heure actuelle (horodatage au format NTP [9])) peut réduire le danger d'attaques de rejeu. Tous les protocoles doivent supporter cette méthode.

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

Si le champ protocol est 2, le message utilise le mécanisme "authentification différée". Dans l'authentification différée, le client demande l'authentification dans un message Solicit, et le serveur répond avec un message Advertise contenant des informations d'authentification. Ces informations d'authentification contiennent une valeur aléatoire générée par la source comme code d'authentification de message (MAC), fournissant l'authentification de message et l'authentification d'entité.

Ici, l'utilisation d'une technique spécifique basée sur le protocole HMAC [8] utilisant le hachage MD5 [16] est définie.

21.4.1. Use of the Authentication Option in the Delayed Authentication Protocol (Utilisation de l'option Authentication dans le protocole d'authentification différé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 replay detection à zéro et omet le champ authentication information. 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 authentication information. Le champ RDM identifie la méthode utilisée pour construire le contenu du champ replay detection.

Le format de l'information d'authentification est le suivant:

     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 (Royaume DHCP)
Le royaume DHCP identifiant la clé utilisée pour générer la valeur HMAC-MD5.

key ID (ID de clé)
L'identificateur de clé identifiant la clé utilisée pour générer la valeur HMAC-MD5.

HMAC-MD5
Le code d'authentification de message généré en appliquant MD5 au message DHCP en utilisant la clé identifiée par le royaume DHCP, le DUID du client et l'ID de clé.

L'expéditeur calcule le MAC en utilisant l'algorithme de génération HMAC [8] et la fonction de hachage MD5 [16]. Le message DHCP entier (avec le champ MAC de l'option Authentication défini à zéro) est utilisé comme entrée à la fonction de calcul HMAC-MD5.

21.4.2. Message Validation (Validation des messages)

Tout message DHCP contenant plusieurs options Authentication doit être rejeté.

Pour valider un message reçu, le destinataire vérifie d'abord que la valeur dans le champ replay detection est acceptable selon la méthode de détection de rejeu spécifiée dans le champ RDM. Ensuite, le destinataire calcule le MAC selon la méthode décrite dans [8]. Le message DHCP entier (avec le champ MAC de l'option Authentication défini à 0) est utilisé comme entrée à la fonction de calcul HMAC-MD5. Si le MAC calculé par le destinataire ne correspond pas au MAC contenu dans l'option Authentication, le destinataire doit rejeter le message DHCP.

21.4.3. Key Utilization (Utilisation des clés)

Chaque client DHCP a un ensemble de clés. Chaque clé est identifiée par <DHCP realm, DUID du client, key id>. Chaque clé a également une durée de vie. Une clé ne peut pas être utilisée après que sa durée de vie a expiré. Les clés du client sont initialement distribuées au client via un mécanisme hors bande. La durée de vie de chaque clé est distribuée avec la clé. Les mécanismes de distribution de clés et de spécification de durée de vie sont hors de portée de ce document.

Le client et le serveur utilisent une clé du client pour authentifier les messages DHCP pendant une session (jusqu'à ce que le client envoie le prochain message Request).

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

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

21.4.4.1. Sending Solicit Messages (Envoi de messages Solicit)

Si le client souhaite utiliser l'authentification lors de l'envoi d'un message Solicit, le client inclut une option Authentication avec les champs protocol, algorithm et RDM nécessaires comme décrit dans la section 21.4. Le client n'inclut pas de replay detection ou d'authentication information dans l'option Authentication.

21.4.4.2. Receiving Advertise Messages (Réception de messages Advertise)

Le client valide tout message Advertise contenant une option Authentication pour le protocole d'authentification différée spécifié en utilisant les tests de validation décrits dans la section 21.4.2.

S'il n'y a pas de messages Advertise contenant des informations d'authentification, ou si les messages Advertise ne passent pas les tests de validation, le comportement du client est contrôlé par la politique locale sur le client. Selon la politique du client, le client peut choisir de répondre aux messages Advertise non authentifiés.

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 du serveur sélectionné par le client, 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 des messages ultérieurs, le client doit utiliser la même clé que le serveur a utilisée 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é du client dans un échange de messages précédent (voir section 21.4.5.1), le client doit générer des informations d'authentification en utilisant la même clé pour toute la session.

21.4.4.5. Receiving Reply Messages (Réception de messages Reply)

Si le client a authentifié l'Advertise accepté, le client doit valider le message Reply associé du serveur. Si le message ne passe pas les tests de validation, le client peut rejeter le Reply et enregistrer l'échec de validation. Si le Reply ne passe pas les tests de validation, le client doit redémarrer le processus de configuration DHCP en envoyant un message Request.

Si le client a accepté un message Advertise sans informations d'authentification ou qui n'a pas passé les tests de validation, le client peut accepter des messages Reply non authentifiés du serveur.

21.4.4.6. Receiving Reconfigure Messages (Réception de messages Reconfigure)

Si le message ne passe pas les tests de validation, le client peut rejeter le Reconfigure et enregistrer l'échec de validation.

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

Lorsqu'un message Solicit contenant une option Authentication est reçu, le serveur sélectionne la clé du client basée sur le DUID du client et la politique de sélection de clé configurée sur le serveur. Le serveur identifie la clé sélectionnée au client dans le message Advertise retourné au client et utilise cette clé pour valider les messages ultérieurs entre le client et le serveur.

21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages (Réception de messages Solicit et envoi de messages Advertise)

Le serveur sélectionne la clé du client et inclut des informations d'authentification dans le message Advertise retourné au client selon la méthode spécifiée dans la section 21.4. Le serveur doit enregistrer l'identificateur de la clé sélectionnée pour le client et utiliser cette même clé pour valider les messages ultérieurs du client.

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

Le serveur utilise la clé identifiée dans le message et valide le message selon la méthode spécifiée dans la section 21.4.2. Si le message ne passe pas les tests de validation, ou si le serveur ne connaît pas la clé identifiée par le champ "key ID", le serveur peut rejeter le message et enregistrer l'échec de validation.

Si le message passe les tests 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 de clé de reconfiguration)

Le protocole d'authentification de clé de reconfiguration fournit une protection contre la mauvaise configuration du client par des messages Reconfigure envoyés par un serveur DHCP malveillant. Dans ce protocole, le serveur DHCP envoie une clé de reconfiguration au client dans l'échange de messages DHCP initial. Le client enregistre la clé de reconfiguration et l'utilise pour authentifier les messages Reconfigure ultérieurs de ce serveur. Le serveur inclut ensuite un HMAC calculé à partir de la clé de reconfiguration dans les messages Reconfigure ultérieurs.

La clé de reconfiguration envoyée du serveur au client et le HMAC dans les messages Reconfigure ultérieurs sont tous deux transportés comme informations d'authentification dans l'option Authentication. Le format des informations d'authentification est défini dans les sections suivantes.

Le protocole de clé de reconfiguration n'est utilisé que lorsque le client et le serveur n'utilisent pas d'autres protocoles d'authentification et lorsque le client et le serveur ont négocié l'utilisation de messages Reconfigure (initié par le serveur).

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

Les champs suivants de l'option Authentication pour le protocole d'authentification de clé de reconfiguration sont définis:

protocol: 3
algorithm: 1
RDM: 0

Le format des informations d'authentification pour le protocole d'authentification de clé de reconfiguration est le suivant:

     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
Le type de données transportées dans le champ Value de cette option:

1: Valeur de clé de reconfiguration (utilisée dans les messages Reply).
2: Digest HMAC-MD5 du message (utilisé dans les messages Reconfigure).

Value (Valeur)
Les données définies par le champ Type.

21.5.2. Server considerations for Reconfigure Key protocol (Considérations serveur pour le protocole de clé de reconfiguration)

Le serveur sélectionne une clé de reconfiguration pour le client pendant un échange de messages Request/Reply, Renew/Reply ou Information-request/Reply. Le serveur enregistre la clé de reconfiguration et envoie cette clé au client dans l'option Authentication du message Reply.

La clé de reconfiguration doit être de 128 bits de longueur et doit être un nombre aléatoire ou pseudo-aléatoire cryptographiquement fort qui n'est pas facilement prévisible.

Pour fournir l'authentification d'un message Reconfigure, le serveur sélectionne une valeur de détection de rejeu selon le RDM sélectionné par le serveur et calcule le HMAC-MD5 du message Reconfigure en utilisant la clé de reconfiguration du client. Le serveur calcule le HMAC-MD5 sur l'ensemble du message Reconfigure DHCP contenant l'option Authentication. Le champ HMAC-MD5 dans l'option Authentication est défini à zéro dans le calcul HMAC-MD5. Le serveur inclut le HMAC-MD5 dans le champ authentication information de l'option Authentication dans le message Reconfigure envoyé au client.

21.5.3. Client considerations for Reconfigure Key protocol (Considérations client pour le protocole de clé de reconfiguration)

Le client reçoit une clé de reconfiguration du serveur à partir du message Reply initial du serveur. Le client enregistre la clé de reconfiguration et l'utilise pour authentifier les messages Reconfigure ultérieurs.

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