Résumé

  • La RFC 3495 faisait de l’option DHCP 122 un aiguillage préalable à l’authentification : elle pouvait désigner les serveurs DHCP autorisés, le serveur de provisionnement, le domaine Kerberos ainsi que les reprises et le délai global.
  • L’exigence ultérieure d’un certificat valide pouvait empêcher l’activation auprès d’une destination hostile, sans authentifier rétroactivement le sélecteur DHCP ni prouver le choix commercial du client.

Dans PacketCable 1.0, le modem câble et l’adaptateur de terminal multimédia pouvaient habiter le même boîtier. Ils restaient pourtant deux équipements IP, avec leurs propres adresses MAC et leurs propres paramètres. Le fournisseur d’accès aux données configurait le modem; le fournisseur de téléphonie configurait le MTA. Une frontière d’autorité traversait donc l’appareil domestique.

La RFC 3495 expliquait que l’entité contrôlant la configuration du modem déterminait aussi quelles entreprises pouvaient configurer le MTA. Elle comparait cette position à celle d’un opérateur local face au choix d’un transporteur longue distance. Le contenu DHCP n’était pas seulement une commodité d’amorçage : il distribuait une capacité commerciale.

Le code officiel 122 contenait des sous-options étiquetées et dimensionnées. Elles annonçaient deux serveurs DHCP de TSP, un serveur de provisionnement, un domaine Kerberos, le recours éventuel au serveur d’octroi de tickets, les paramètres de reprise des échanges AS et AP, puis une minuterie de provisionnement. Le code expérimental 177 fut abandonné; au-delà de 255 octets, la concaténation de la RFC 3396 s’appliquait.

La syntaxe était rigoureuse. Une adresse IPv4 occupait quatre octets dans l’ordre réseau. Un nom complet suivait l’encodage de la RFC 1035, avec zéro terminal et sans compression DNS. Le domaine prenait la forme d’un nom en capitales. Une suite d’octets conforme prouvait cependant une seule chose : le parseur pouvait en tirer une instruction. Elle ne prouvait ni l’existence de l’hôte, ni la loyauté de la résolution, ni l’acceptation par un KDC.

Le sens du message fixe aussi la responsabilité. Les clients demandaient l’option grâce aux options 55 et 60; le serveur sélectionnait les sous-options selon la classe d’équipement et les spécifications CableLabs. Le client ne remplissait jamais lui-même CCC dans sa requête. Une capture montrant un domaine est donc le reçu d’une instruction fournie par une autorité de configuration, pas la preuve d’un choix autonome de l’abonné.

La RFC décrivait plusieurs détournements. De mauvaises adresses pouvaient provoquer une panne ou envoyer le trafic vers un observateur. Un domaine falsifié pouvait conduire le MTA vers le mauvais KDC. Un TSP malveillant pouvait modifier cette désignation pour récupérer le client d’un concurrent. La même interface qui rendait le provisionnement automatique pouvait déplacer silencieusement son bénéficiaire.

Une première défense appartenait au CMTS. Correctement configuré, il ne relayait les requêtes qu’aux serveurs DHCP explicitement admis et ne laissait descendre que le trafic provenant des plages autorisées. L’expression « correctement configuré » n’est pourtant pas une propriété du paquet. Elle demande la configuration du CMTS, l’état effectif des filtres et des observations de trafic.

La seconde défense intervenait plus tard. Même redirigé vers un KDC, le MTA devait présenter des certificats valides avant l’activation du service. Un KDC non autorisé pouvait ainsi être bloqué. Mais la validation consommait des ressources et offrait elle-même une voie de déni de service. Le refus du certificat prouvait un échec au contrôle tardif; il ne validait pas le domaine reçu plus tôt.

Un certificat accepté ne rétablissait pas davantage le mandat commercial. Le texte envisageait le cas d’un TSP malveillant mais certifié, supposait que les TSP admis cohabiteraient pacifiquement et renvoyait le détournement de clientèle au règlement administratif. L’identité cryptographique du fournisseur et le consentement du client restaient deux reçus différents.

Les reprises augmentaient le coût d’une mauvaise orientation. Les échanges AS et AP disposaient chacun d’un délai initial, d’un maximum et d’un nombre d’essais. Une minuterie extérieure imposait la durée du provisionnement puis relançait toute la procédure à son expiration. Une valeur nulle désactivait cette limite; elle ne signifiait pas que le service était prêt.

Cette histoire ne répète pas celle des RFC voisines. La RFC 3361 désignait des candidats SIP; la RFC 3396 reconstruisait une option longue; la RFC 3397 livrait une liste de recherche de domaines; la RFC 3442 installait des routes. La RFC 3495 plaçait les destinations mêmes de l’authentification et leur politique temporelle dans un canal antérieur à cette authentification.

La chaîne de preuve complète va des octets à l’usage : réception, analyse, sélection du domaine et du serveur, résolution, routage, contact du KDC, validation du certificat, échange Kerberos, ticket, provisionnement dans le délai, conservation du TSP choisi, service téléphonique. Dire « authentifié » sans préciser l’échelon efface précisément l’autorité que l’histoire permet d’examiner.

Sources