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.