Résumé

  • Dans RFC 3079, les valeurs maîtresses ne chiffraient jamais les données. Elles alimentaient des dérivations asymétriques qui produisaient des clés transitoires distinctes pour l’émission et la réception.
  • Une dérivation correcte attestait seulement la relation entre des entrées et des octets de sortie. Elle n’attestait ni la même première authentification aux deux extrémités, ni la bonne correspondance des sens, ni le mode MPPE négocié, ni la livraison applicative.

Une hiérarchie cachée derrière un mot

Le mot « maître » invite à imaginer la clé qui commande tout. RFC 3079 établissait exactement la limite inverse : les clés maîtresses ne servent jamais à chiffrer ou déchiffrer. Leur fonction consiste à engendrer d’autres valeurs.

Dans la branche MS-CHAP-2, le double hachage du mot de passe et le NT-Response produisaient d’abord une valeur maîtresse de seize octets. GetAsymmetricStartKey choisissait ensuite une branche selon deux coordonnées : émission ou réception, client ou serveur. GetNewKeyFromSHA fabriquait enfin la clé transitoire chargée dans le contexte RC4 correspondant.

Un journal « master key OK » s’arrêtait donc trop tôt. Il ne disait pas quel libellé de rôle avait été appliqué, où la sortie avait été installée, ni si le pair avait choisi la branche complémentaire. Deux systèmes pouvaient réussir chacun leur calcul et rester incapables de lire leurs paquets respectifs.

Des sources d’authentification qui restent distinctes

Publié en mars 2001 comme RFC informationnelle, RFC 3079 voulait offrir une référence ouverte aux tiers devant interopérer avec des produits Microsoft. Le document ne définissait ni la négociation CCP, ni le format de paquet, ni les changements de clé pendant la session : RFC 3078 portait ces sujets.

Trois lignées étaient décrites. MS-CHAP-1 tirait ses clés faibles du hachage LAN Manager et sa branche 128 bits du hachage Windows NT associé au challenge. MS-CHAP-2 utilisait le hachage NT et le NT-Response pour les trois forces. EAP-TLS partait d’un secret maître TLS exporté.

Le fait que ces lignées convergent vers MPPE ne les rendait pas équivalentes. Une preuve utile devait conserver le type d’authentification, le pair appelant, le premier échange retenu, les challenges ou la génération TLS et le lien concerné. Huit octets installés pouvaient représenter 40 ou 56 bits effectifs ; seize octets pouvaient provenir d’événements d’authentification différents.

RFC 2759 précisait Peer-Challenge, Authenticator-Challenge, ChallengeHash, NT-Response et AuthenticatorResponse pour MS-CHAP-2. RFC 2433 décrivait son prédécesseur. RFC 2716 encadrait EAP-TLS dans PPP. Ces textes validaient des entrées possibles, pas l’ouverture ultérieure de CCP.

La « première authentification » faisait partie de l’identité

RFC 3079 imposait que les clés initiales des deux sens proviennent des identifiants du pair ayant lancé l’appel. Quand un challenge intervenait, celui de la première authentification devait être retenu, y compris en authentification bilatérale et pour chaque lien d’un faisceau multilink.

Cette règle devient fragile dès que l’architecture distribue ses responsabilités. Le serveur d’identité peut ne garder que la réussite la plus récente. Le contrôleur de faisceau peut agréger des liens sans conserver l’échange qui les a initialisés. Un châssis de relève peut recevoir un nom d’utilisateur et un état « authentifié », mais pas la génération de challenge nécessaire.

Dans un faisceau réparti sur plusieurs châssis, le RFC rendait les implémentations responsables de la production des bonnes clés sur toutes les machines. La formule n’organisait ni la réplication ni le basculement. Le véritable identifiant de session comprenait donc l’événement d’authentification, le rôle, le lien et la génération de dérivation.

Émettre ici voulait dire recevoir ailleurs

Les constantes de GetAsymmetricStartKey encodaient une relation entre deux extrémités. La branche d’émission du serveur correspondait à la branche de réception du client ; l’autre paire fonctionnait en sens inverse. La section EAP-TLS le résumait sans ambiguïté : la clé d’émission d’un côté est la clé de réception de l’autre.

Une propriété nommée send_key n’était donc pas portable telle quelle. Copier ce champ dans le send_key du pair conservait l’étiquette et détruisait la relation. La longueur, la réussite locale et même un test vectoriel conforme ne détectaient pas nécessairement cette inversion.

Le reçu pertinent joint les deux visions sans révéler le secret : identité des extrémités, rôle client/serveur, direction locale, direction distante, empreinte de génération et empreinte de la clé transitoire. Il doit montrer que la sortie de A rejoint l’entrée de B et réciproquement.

La force effective était modifiée après le calcul

Les branches 40 et 56 bits utilisaient des valeurs de huit octets ; la branche 128 bits en utilisait seize. Mais les deux premières subissaient encore une réduction volontaire : trois octets initiaux étaient remplacés par des constantes pour 40 bits, un octet pour 56 bits.

EAP-TLS ajoutait une normalisation de longueur. Une valeur asymétrique trop courte devait être complétée de zéros à gauche ; une valeur trop longue, tronquée. Une même longueur finale pouvait ainsi cacher des entrées et des opérations différentes.

Les exemples complets de RFC 3079 permettaient de vérifier l’arithmétique. Ils ne prouvaient ni l’origine du secret dans une session réelle, ni le transport sûr depuis un serveur EAP séparé, ni le choix négocié de 128 plutôt que 40 bits. La section sécurité rappelait d’ailleurs que la clé initiale MS-CHAP-1 à 40 bits se répétait avec les mêmes identifiants et recommandait de l’éviter si possible.

Cette observation historique n’est pas une recommandation contemporaine en faveur de RC4, de LAN Manager ou de MS-CHAP. Elle montre qu’une longueur annoncée n’épuise jamais l’analyse de provenance et de sécurité.

Après la dérivation restait toute la session

RFC 3078 exigeait que PPP atteigne la phase Network-Layer Protocol et CCP l’état Opened avant le premier paquet MPPE. RFC 2548 traitait d’un autre passage : le transport des clés par sens dans RADIUS, avec des proxies capables de déchiffrer et rechiffrer les attributs protégés.

Une authentification réussie ne prouvait donc pas que le secret avait atteint l’authentificateur PPP. Une clé reçue ne prouvait pas son association au bon lien. Une paire directionnelle correcte ne prouvait pas l’accord CCP. CCP Opened ne prouvait pas la synchronisation durable. Un paquet déchiffré ne prouvait pas son traitement par l’application.

La discipline des couches de réalité de Lu Heng aide à lire cette chaîne sans confondre les noms et les actes. « Maître », « émission », « authentifié » ou « 128 bits » sont des symboles. Le code en exécution doit relier les couches, et les preuves doivent montrer chaque transition.

RFC 3079 a rendu ce minimum reproductible. Sa leçon demeure étroite : la dérivation ouvre l’étape suivante ; elle ne clôt pas la preuve du service.

Sources