Résumé

  • RFC 3526 normalise des paramètres MODP communs pour IKE, du groupe 5 de 1536 bits aux groupes 14 à 18 de 2048 à 8192 bits. Il refuse pourtant d’associer mécaniquement chaque groupe à une force AES et exige que l’exposant ne devienne pas le maillon faible.
  • Le reçu complet doit relier l’identité des paramètres à la politique locale, à l’entropie et à la fraîcheur de l’exposant, au contrôle de la valeur publique reçue, à l’authentification, à la suite entière, au cycle de vie des secrets et au trafic observé.

Un groupe Diffie-Hellman a une propriété séduisante pour l’audit : tout le monde peut voir sa définition. Le nombre premier, le générateur et l’identifiant sont publiés. Le geste qui fabrique le secret privé doit, au contraire, rester caché puis disparaître.

Cette différence de visibilité peut renverser la logique du contrôle. On examine longuement ce qui est public parce que c’est facile à montrer, puis on traite l’acte privé comme s’il héritait automatiquement de la qualité du catalogue.

RFC 3526, publié en mai 2003 sur la voie Standards Track et aujourd’hui répertorié au niveau Proposed Standard, ne donne pas cette garantie. Il coordonne des paramètres; il ne certifie pas l’exécution.

Une bibliothèque de paramètres n’est pas un verdict de session

Le document consigne le groupe 5 de 1536 bits, déjà utilisé, puis attribue les identifiants 14, 15, 16, 17 et 18 à des groupes de 2048, 3072, 4096, 6144 et 8192 bits. Tous emploient le générateur 2 et des nombres premiers construits selon les critères indiqués.

La normalisation évite que deux pairs donnent des sens différents au même identifiant. Elle rend les paramètres inspectables, réutilisables et comparables. C’est une fonction d’interopérabilité essentielle.

Elle ne décrit pas la source aléatoire du terminal, la valeur privée choisie, le test appliqué à l’entrée du pair, la politique qui a permis le groupe, le mécanisme d’identité ni la réussite du trafic protégé.

Le reçu exact dit donc : ces paramètres publics ont été sélectionnés. Toute affirmation sur la sécurité de la session doit ajouter les événements locaux qui ne figurent pas dans le catalogue.

Les estimations ne se transforment pas en table commerciale

L’introduction compare plusieurs estimations du coût des groupes finis face aux forces symétriques. Les chiffres cités divergent fortement, surtout pour les clés AES de 192 et 256 bits.

Les auteurs choisissent la prudence intellectuelle : ils définissent plusieurs groupes sans décider lequel « correspond » à chacune des trois tailles AES. Ils ne vont pas au-delà de 8192 bits, jugés alors trop coûteux pour un usage pratique.

Un rapport qui convertit le groupe 18 en promesse automatique de « sécurité 256 bits » invente donc une équivalence que le RFC a expressément refusé d’établir. Le nombre de bits du module n’est pas une unité universelle de résultat.

La bonne décision dépend d’un horizon, d’un modèle d’attaque, du reste de la suite, des capacités de l’équipement et d’une politique révisable. Le document fournit des options; il ne remplace pas ce jugement.

L’exposant est l’acte privé que le catalogue ne voit pas

RFC 3526 précise que la taille de l’exposant doit correspondre aux autres parties du système et ne doit pas constituer le maillon faible. Il demande plus du double d’entropie par rapport à la force visée; son exemple exige plus de 256 bits de hasard pour une force de 128 bits.

La taille allouée en mémoire ne prouve pas l’entropie. Un tampon large peut être rempli par une source biaisée, répétée ou mal initialisée. Étendre ensuite la représentation ne crée pas l’imprévisibilité absente.

Le contrôle ne doit pas davantage enregistrer l’exposant secret. Une telle « preuve » deviendrait une fuite de clé. Il faut conserver des informations non secrètes : générateur approuvé et version, état de ses tests, politique de longueur, demande de fraîcheur et liaison protégée à l’événement.

Une immense structure mathématique n’annule pas une action locale prévisible. La force visible du groupe et la qualité invisible du secret sont deux preuves différentes.

La valeur publique du pair exige un contrôle séparé

RFC 6989 décrit ensuite les tests du destinataire IKEv2. Pour les groupes MODP à nombre premier de Sophie Germain auxquels appartiennent ceux de RFC 3526, le pair vérifie que la valeur reçue r respecte strictement 1 < r < p-1.

L’identifiant négocié indique quelle règle employer; il ne démontre pas son exécution. Un message peut annoncer le groupe 14 et transporter une valeur qui doit être rejetée.

Le même RFC distingue les groupes à petits sous-groupes définis ailleurs et encadre la réutilisation des valeurs privées. Selon la famille et la pratique de réutilisation, les contrôles et la génération fraîche ne sont pas interchangeables.

Le journal utile garde l’empreinte de la valeur reçue, le profil de validation, la version de l’implémentation et la branche prise. La mention « DH accepté » ne permet pas de savoir si l’on parle de paramètres connus, d’entrée valide ou de politique autorisée.

La capacité obligatoire n’impose pas la politique locale

RFC 7296 exige des contrôles de gestion pour les suites IKEv2 acceptables. L’implémentation compare les Transform IDs transmis avec la configuration locale et rejette les propositions non autorisées. Une suite obligatoire à implémenter n’est pas obligatoire à activer.

Cette séparation empêche un registre externe de devenir la politique du déploiement. La présence d’un identifiant dans une norme ou un produit ne décide pas son usage pour un objectif particulier.

RFC 8247 montre que les exigences changent : à sa publication, le groupe 14 devient MUST à implémenter, alors que le groupe 5 passe à SHOULD NOT. Le texte rappelle aussi le coût calculatoire des groupes extrêmes pour une passerelle VPN ou un appareil contraint.

Il faut donc enregistrer l’offre complète, le choix, la version de politique, l’autorisation et les alternatives refusées. « Pris en charge » décrit l’inventaire; « accepté ici » décrit une décision. Aucun des deux ne prouve le résultat.

L’accord mathématique ne nomme pas le pair

Un échange Diffie-Hellman sans authentification partage une valeur avec le participant effectif, pas nécessairement avec l’identité voulue. IKE ajoute des méthodes d’authentification et lie les éléments de l’échange. RFC 3526 ne remplace pas ce travail.

La taille du groupe ne valide ni chaîne de certificats, ni identité de clé prépartagée, ni méthode EAP, ni correspondance entre le nom accepté et le sujet autorisé.

Un écran peut afficher 4096 bits et un handshake vert, puis laisser un système en aval conclure qu’une entreprise ou un appareil a été reconnu. La conclusion d’identité vient d’un autre reçu et doit rester attribuée à ce reçu.

Méthode, chemin de confiance, politique de validation, identité revendiquée et identité retenue doivent être corrélés à l’échange sans être absorbés par le Transform ID.

La suite entière fixe encore le plafond

RFC 8247 rappelle que la sécurité dépend à la fois des algorithmes, des clés et de l’ingénierie qui empêche les contournements non cryptographiques. Un grand groupe ne répare pas une PRF faible, une authentification défaillante, un stockage exposé ou un chemin qui évite le tunnel.

Il impose aussi un coût. Une exponentiation plus grande consomme davantage de calcul; réalisée trop tôt, elle peut élargir une surface d’épuisement de ressources. Ce n’est pas une raison de choisir un groupe faible, mais une raison de documenter le compromis et l’ordre des contrôles.

La suite doit être évaluée comme un graphe de dépendances. La promesse effective est bornée par les composants pertinents les plus faibles et leur composition, pas par le nombre le plus impressionnant d’un export de conformité.

RFC 7919, consacré au FFDHE négocié dans TLS, fournit une comparaison ultérieure et un autre contexte. Il ne réécrit pas RFC 3526 et ne prouve rien sur une session IKE.

Le registre coordonne le présent, il n’observe pas l’exécution

Le registre IANA IKEv2 conserve les groupes 5 et 14 à 18 avec RFC 3526 comme référence et RFC 6989 pour les tests du destinataire. Il indique le sens d’un numéro et la documentation applicable.

Il ne voit pas si un équipement génère un secret frais, vérifie r, applique la politique, authentifie le bon pair, détruit une ancienne clé ou transporte le trafic attendu.

RFC 9395 a déprécié IKEv1 et fermé ses registres. Sa liste d’algorithmes nouvellement dépréciés ne contient aucun groupe Diffie-Hellman. Ce fait précis ne rend pas tous les groupes restants équivalents ni toutes les anciennes configurations sûres.

Statut documentaire, inscription au registre, capacité d’implémentation et choix d’exploitation répondent à quatre questions. Les fusionner donne à une ligne de registre l’autorité d’une machine qu’elle n’a jamais observée.

Construire la chaîne du groupe au résultat

Le premier reçu contient version du protocole, RFC, Transform ID et empreinte des paramètres. Le suivant conserve l’offre ordonnée, la suite choisie, le contexte anti-downgrade et la décision de politique locale.

La génération privée fournit une preuve non secrète de source, santé, fraîcheur et règle d’exposant. L’entrée du pair fournit son empreinte, le profil de test et le verdict. L’exposant lui-même ne doit pas entrer dans la télémétrie ordinaire.

L’authentification apporte méthode, identifiant, chemin de confiance et politique. La dérivation apporte PRF, algorithmes, nonces et création de SA. Le cycle de vie apporte renouvellement, non-réutilisation et destruction vérifiable.

Enfin, le réseau et l’application répondent à la promesse réelle : paquets protégés, échecs d’intégrité, sélecteurs, pair attendu et opération terminée. La négociation est une étape, pas le dernier reçu.

Limite des preuves

Cet Article ne nomme aucune implémentation, fournisseur, opérateur, VPN, passerelle, paire, personne, session, attaque ou compromission. Il ne mesure aucune adoption, entropie, validation, réutilisation, performance ou conséquence commerciale actuelle.

RFC 3526 est présenté comme document Standards Track de mai 2003, actuellement enregistré au niveau Proposed Standard. RFC 6989, RFC 7296, RFC 8247 et RFC 9395 gardent chacun leur date et leur portée. Ils ne prouvent pas qu’un système déterminé les exécute.

Les notes de Heng Lu sur l’autorité et le code en service sont des perspectives éditoriales déclarées. Elles servent à séparer coordination publique, preuve locale et résultat; elles ne témoignent pas de l’intention de l’IETF.

La conclusion reste étroite : agrandir le groupe renforce un composant mathématique, mais seul l’ensemble des reçus permet de qualifier l’échange réel.

Sources