Résumé

  • La version 04 du projet EAP-PPT, datée du 30 septembre, abandonne les clés MSK et EMSK que la version 03 voulait tirer de l’exportateur TLS du tunnel extérieur. Le texte reste un Internet-Draft du groupe EMU, au stade I-D Exists : ni RFC ni constat de déploiement.
  • Un jeton Privacy Pass est présenté puis vérifié. Cette opération peut autoriser un pair, mais elle n’établit pas entre ce pair et le serveur EAP-PPT un secret commun indépendant du tunnel. Présenter une clé issue du tunnel comme une preuve fournie par la méthode intérieure surestimerait donc la liaison cryptographique.

Dans une architecture d’accès, la question « une clé existe-t-elle ? » est trop courte. Il faut savoir qui pouvait la calculer. La version précédente d’EAP-PPT prévoyait 128 octets produits par l’exportateur de la session TLS porteuse, puis deux blocs de 64 octets désignés MSK et EMSK. Le nouveau texte retire cette construction. Sa section 5.7 interdit à une mise en œuvre de déclarer au mécanisme EAP porteur un matériau de clé provenant d’EAP-PPT. Ce n’est pas un simple changement de nom : le statut de preuve de ces octets change.

Le jeton présenté par le pair est un titre au porteur. Selon son type, le serveur le vérifie soit avec la clé publique de l’émetteur, soit avec un secret qu’il partage avec cet émetteur. Dans aucun des deux cas la vérification ne met en jeu un secret partagé avec le pair. Celui qui termine le tunnel TLS peut déjà calculer une valeur dérivée de cette session. Lui attribuer l’étiquette « clé de la méthode intérieure » n’ajoute pas le témoin indépendant qui permettrait de distinguer le porteur légitime du tunnel d’un relais. La version 04 expose ce raisonnement au lieu de laisser l’exportateur tenir lieu de preuve.

Le périmètre est important pour lire les conclusions du projet. L’acceptation du jeton relève de l’autorisation. L’authentification du serveur et le matériau remis à l’authentificateur relèvent du protocole EAP fondé sur le tunnel TLS. Le tableau des garanties de la nouvelle version dit « pas de dérivation de clés » et « pas de liaison cryptographique » pour EAP-PPT, tout en conservant une possibilité de channel binding. Ce dernier échange compare notamment la vision du réseau par le pair aux informations détenues côté serveur ; il n’implique pas qu’un secret nouveau ait été négocié par Privacy Pass.

Une conséquence apparaît dans la nouvelle section de sécurité. Un adversaire qui parvient à faire accepter son certificat au pair peut établir un tunnel avec lui, relayer l’échange EAP-PPT vers un véritable serveur et dépenser le jeton pour son propre accès. Le texte situe la défense première dans la validation stricte du certificat : ancres de confiance propres au réseau rejoint, identité attendue du serveur et refus d’un certificat qui échoue à ces vérifications, sans dérogation improvisée de l’utilisateur ni confiance au premier contact.

La cohabitation des serveurs EAP et EAP-PPT, la liaison de canal, une durée de vie courte et la détection de double dépense limitent certains effets ; le projet ne les présente pas comme une preuve générale d’absence de relais.

La même révision remplace aussi le codage JSON par des objets TLV et précise leur analyse. Ces modifications sont substantielles, mais elles ne prouvent aucun incident ni défaut chez un fournisseur. Le fait éditorial ici est plus délimité : les auteurs ont supprimé une revendication de clé qui pouvait être satisfaite par le tunnel lui-même. Le texte ne transforme pas le jeton en mécanisme de clé ; il rend plus visible la répartition réelle des garanties.

Sources