Résumé

  • La RFC 3129 voulait fonder les clés des associations de sécurité IPsec sur les clés de session contenues dans les tickets Kerberos, afin de réduire la multiplication des secrets bilatéraux.
  • Elle disait expressément que KINK ne remplaçait pas IKE : la centralisation gagnait en administration et en économie de calcul, mais dépendait d'un tiers de confiance actif.
  • La complexité n'était pas abolie. Elle quittait en partie les pairs pour se concentrer dans la disponibilité du KDC, les royaumes, les horloges, les noms et l'autorisation locale.

La formule la plus importante de la RFC 3129 est presque administrative. Si chaque paire de machines IPsec partage un secret différent, la distribution des clés croît, dans le modèle du texte, comme O(n²). Si chaque principal entretient sa relation durable avec un centre de distribution de clés Kerberos, le nombre de secrets de long terme se rapproche de O(n). Ce raccourci ne calcule pas tous les coûts d'exploitation. Il révèle toutefois le problème que le document voulait résoudre : une architecture de sécurité peut devenir ingérable avant même que sa cryptographie ne soit cassée.

L'IPsec de 1998 avait déjà séparé deux fonctions. La RFC 2401 définissait les associations de sécurité et la protection des paquets par AH ou ESP. La RFC 2409 décrivait IKE, échange de pair à pair qui authentifiait les extrémités, négociait des paramètres et produisait du matériau de clé. Cette autonomie constituait l'une de ses forces : deux pairs pouvaient établir une relation sans faire intervenir, au moment de l'échange, une autorité centrale.

Mais l'autonomie distribuait aussi la charge. Chaque pair devait comprendre la politique du site, vérifier l'identité de l'autre et supporter les calculs nécessaires. Les certificats X.509 rendaient l'authentification extensible, au prix des chaînes de confiance et des signatures. Diffie–Hellman fournissait un secret partagé, au prix d'un calcul que le texte jugeait coûteux et exposé au déni de service. Les secrets prépartagés évitaient certains de ces mécanismes, mais reconstituaient le maillage O(n²).

Kerberos proposait une autre géographie. Selon la RFC 1510, un client s'authentifiait auprès d'un KDC, obtenait un ticket pour un service et recevait une clé de session. Le service pouvait ouvrir le ticket et retrouver la même clé. La RFC 3129 demanda que KINK utilise cette clé de session comme base des clés des associations IPsec.

Le déplacement était institutionnel autant que technique. Les secrets durables reliaient les principaux au KDC plutôt que chaque pair à tous les autres. Une authentification initiale à clé publique, via ce qui deviendrait PKINIT, pouvait être amortie sur plusieurs tickets. Une partie de la politique devenait administrable dans le royaume, au lieu d'être répétée sur des équipements dont le propriétaire ne pouvait pas toujours garantir la discipline.

Le texte refusa pourtant le récit facile du remplacement. KINK ne devait pas remplacer IKE. IKE possédait une propriété que KINK ne pouvait reproduire : deux pairs pouvaient s'authentifier et échanger des clés sans tiers actif. KINK devenait pertinent là où un tiers de confiance existait déjà et où sa participation était souhaitée. La différence ne portait donc pas uniquement sur la vitesse d'un échange, mais sur la forme de l'autorité.

Les exigences encadraient précisément cette autorité. L'un ou l'autre pair IPsec devait pouvoir commencer la négociation, qu'il soit un « client » Kerberos ne possédant qu'un TGT ou un service muni d'un keytab. Le mode utilisateur-à-utilisateur devait couvrir les situations où le répondant ne pouvait pas déchiffrer un ticket de service classique. Les pairs devaient participer à plusieurs royaumes et supporter l'authentification initiale symétrique ou publique.

La gestion du temps était elle aussi explicite, car un ticket est une autorité limitée par une horloge. Le protocole devait traiter convenablement un décalage absolu. Il devait aussi permettre de renouveler les clés sans assistance du KDC tant que le ticket de session restait valide. Le centre n'était donc pas destiné à approuver chaque paquet ni même chaque renouvellement. Il établissait une matière partagée et une durée pendant laquelle les pairs pouvaient agir.

Le reste demeurait considérable. KINK devait créer, modifier, renouveler et supprimer des associations ; négocier des suites cryptographiques ; installer des sélecteurs de flux ; prendre en charge les modes transport et tunnel, AH et ESP, IPv4 et IPv6. L'identité authentifiée par Kerberos ne décidait pas, à elle seule, des préfixes qu'un pair pouvait représenter. Cette autorisation restait locale.

Cette frontière explique pourquoi « authentifié » ne signifie pas « autorisé ». Un ticket peut prouver une identité et transporter une clé de session. Il ne peut pas accorder spontanément le droit d'établir un tunnel pour un réseau entier. Si la politique IPsec associe mal un principal à un sélecteur, la centralisation de l'identité peut accélérer une mauvaise décision au lieu de la corriger.

La RFC 3129 ne livrait pas encore le protocole. Son statut était Informational et son objet était d'établir des exigences. La RFC 4430, publiée en 2006 comme Proposed Standard, spécifia ensuite KINK en s'appuyant sur ce cadre. Confondre ces étapes transformerait une intention architecturale en fait de déploiement. Ni l'une ni l'autre ne prouve que KINK a supplanté IKE dans les réseaux réels.

Le contexte a continué à bouger. La RFC 4120 remplaça la première spécification Kerberos V5. La RFC 3961 organisa les profils de chiffrement et de somme de contrôle de Kerberos. La RFC 4556 normalisa PKINIT. IKE devint IKEv2 dans la RFC 4306, puis la RFC 7296. La RFC 6113 généralisa la préauthentification Kerberos. L'histoire ne convergeait pas vers un vainqueur unique ; elle accumulait plusieurs répartitions possibles de la confiance.

La comparaison O(n) contre O(n²) doit donc rester à sa juste place. Elle décrit la garde des secrets de long terme dans un modèle simple. Elle ne compte ni les relations inter-royaumes, ni la rotation des keytabs, ni la sauvegarde du KDC, ni la synchronisation des horloges, ni l'audit, ni les capacités, ni les règles locales. Le maillage devient plus petit, mais chaque nœud central devient plus lourd de conséquences.

Une panne illustre cette nuance. Des associations déjà installées peuvent continuer. Des tickets encore valides peuvent permettre un renouvellement local, précisément parce que la RFC l'exigeait. En revanche, de nouveaux principaux, des tickets expirés ou de nouvelles relations de service peuvent avoir besoin du KDC. La bonne question n'est pas « le KDC est-il en panne ? », mais « à quel moment chaque flux doit-il de nouveau dépendre de lui ? ».

Un compromis du KDC inverse l'avantage. Les journaux centraux peuvent améliorer l'attribution en reliant principal, ticket et durée. Mais une autorité compromise peut aussi distribuer une confiance crédible à grande échelle. La concentration rend la gouvernance plus visible et l'échec plus systémique.

Les considérations de sécurité de la RFC 3129 le reconnaissaient : les associations produites hériteraient de l'union des faiblesses d'IPsec et de Kerberos. Composer deux mécanismes ne fait pas disparaître leurs défauts. Leur jonction peut même en créer un nouveau.

La valeur historique du document réside là. Il a inscrit l'exploitation dans les exigences cryptographiques. Il ne suffisait plus de demander si deux machines pouvaient calculer la même clé. Il fallait savoir qui entretenait les relations, qui appliquait la politique, combien de fois le calcul était répété et quelle institution rendait l'ensemble gouvernable.

Le KDC ne supprimait pas la confiance. Il la rendait réutilisable et administrable, mais aussi concentrée. RFC 3129 eut la prudence de documenter ce marché avant de prétendre avoir livré le protocole.

Sources