Résumé

  • L’authentification différée de RFC 3118 reposait sur un secret partagé, fourni hors bande à un client et à un serveur DHCP dans un même domaine administratif.
  • Le client pouvait encore accepter une offre non authentifiée si sa politique locale l’autorisait ; le RFC recommandait un réglage configurable qui les refusait par défaut.

L’option ne créait pas d’identité universelle

DHCP est surtout connu comme le protocole qui permet à un hôte de rejoindre un réseau et d’obtenir une adresse et d’autres paramètres. Cette facilité comporte un risque : un serveur pirate ou activé par erreur peut proposer une passerelle, un résolveur ou une adresse incorrects. Le serveur peut aussi recevoir une demande d’un client qui se fait passer pour un client autorisé ou cherche à épuiser un pool. Publié en juin 2001, RFC 3118 cherchait à authentifier l’origine et le contenu des messages DHCP sans reconstruire le protocole.

Son option 90 exposait le mécanisme sur le fil : protocole, algorithme, méthode de détection des rejeux, valeur anti-rejeu et information d’authentification. Une seule option réunissait pourtant plusieurs questions distinctes : quelle procédure était utilisée, comment reconnaître un ancien message et quel secret liait le paquet à son pair ?

RFC 3118 distinguait un simple jeton de configuration de l’authentification différée. Le jeton ne fournissait qu’une faible authentification de l’entité, sans authentification du message ; le RFC le décrivait comme une protection élémentaire contre un serveur DHCP lancé par inadvertance. Le mécanisme différé employait HMAC-MD5 et un secret partagé. Il s’agit ici d’un choix historique, pas d’une recommandation pour de nouveaux systèmes.

L’authentification commençait avant la découverte

Dans le mécanisme différé, le client demandait l’authentification dans DHCPDISCOVER. Un serveur choisissait un secret et renvoyait des informations d’authentification dans DHCPOFFER. Le client retenait une offre et envoyait DHCPREQUEST avec le secret correspondant ; un accusé de réception authentifié devait ensuite être validé. La détection des rejeux accompagnait cet échange : un authentificateur valide ne pouvait pas être simplement recopié d’un ancien paquet.

La séquence exigeait donc une relation préalable. RFC 3118 prévoit que le client reçoive sa clé hors bande. Le serveur devait connaître, ou obtenir de manière sûre, les clés des clients autorisés. Un secret partagé à grande échelle permettait à quiconque le détenait d’usurper un autre détenteur ; lorsque l’identité individuelle comptait, le RFC demandait des clés uniques. L’échange sur le réseau dépendait ainsi d’un système de provisionnement que DHCP ne définissait pas.

Cette limite était délibérée. RFC 3118 ne traitait pas l’itinérance entre domaines administratifs. Il visait un usage intradomaine où l’échange séparé d’un secret était possible, et signalait que la méthode pouvait mal passer à l’échelle si les clients rejoignaient plusieurs domaines. Un MAC confirmait qu’un message correspondait à une clé configurée ; il ne créait ni identité mondiale, ni accord d’itinérance, ni droit d’accès au réseau.

Les relais et l’acceptation locale faisaient aussi partie du modèle

Les relais DHCP peuvent modifier giaddr et hops, puis ajouter des informations de relais. RFC 3118 précisait comment traiter ces champs dans le calcul d’authentification afin qu’un relais légitime n’invalide pas le contrôle. Cela définissait un chemin via les intermédiaires ; cela ne transformait pas chaque relais en autorité d’identité.

Le choix du client en l’absence d’authentification est encore plus révélateur. Si aucune offre ne porte une authentification valide, la politique locale pouvait autoriser une offre non authentifiée. Le RFC exigeait que le client puisse être configuré pour les refuser et recommandait ce refus par défaut. En cas d’acceptation, il conseillait d’en informer l’utilisateur et de consigner l’événement. La sécurité dépendait donc aussi de la politique de repli, pas seulement du MAC de l’option.

On pourrait croire que la présence d’une option d’authentification garantit que chaque configuration acceptée l’a été. RFC 3118 met en garde contre cette conclusion. Il définit un mécanisme et une valeur par défaut prudente, mais laisse aux administrateurs et aux clients la responsabilité du choix local de confiance.

Les sources ne montrent ni l’ampleur de l’implémentation ou de la configuration de l’option 90, ni une réduction mesurée des attaques. Une norme définit un comportement possible ; adoption et résultats nécessitent d’autres preuves. L’apport historique de RFC 3118 est plus circonscrit : l’authentification DHCP restait un arrangement local, limité par le détenteur du secret, les serveurs et relais concernés, et l’acceptation éventuelle d’une alternative non signée.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3118.html
  2. https://www.rfc-editor.org/info/rfc3118
  3. https://datatracker.ietf.org/doc/rfc3118/
  4. https://www.rfc-editor.org/rfc/rfc2131.html
  5. https://www.rfc-editor.org/rfc/rfc2132.html
  6. https://www.rfc-editor.org/rfc/rfc3046.html
  7. https://www.rfc-editor.org/rfc/rfc2104.html
  8. https://www.rfc-editor.org/rfc/rfc1321.html
  9. https://www.rfc-editor.org/rfc/rfc2119.html
  10. https://www.rfc-editor.org/rfc/rfc951.html
  11. https://www.rfc-editor.org/rfc/rfc4361.html
  12. https://www.rfc-editor.org/rfc/rfc6842.html
  13. https://www.rfc-editor.org/rfc/rfc8415.html
  14. https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml