Résumé

  • draft-ietf-emu-eap-ppt-04 retire les 128 octets que la version précédente dérivait de l’exportateur TLS externe et précise désormais qu’EAP-PPT ne produit ni MSK ni EMSK.
  • Le jeton Privacy Pass est un titre au porteur transmis dans le tunnel. Son terminateur voit le jeton et calcule la même valeur d’exportation : ces octets ne prouvent donc pas que détenteur et terminaison sont une seule entité.

L’exportateur cryptographique a répondu exactement à la demande : 128 octets sont sortis. L’erreur venait de l’autorité que le protocole risquait de leur attribuer, non de leur calcul.

La révision 03 de Extensible Authentication Protocol (EAP) Using Privacy Pass Token dérivait ces octets du tunnel TLS porteur sous le libellé EXPORTER_EAP_PPT_Key_Material. Le contexte contenait le type EAP et le jeton racheté. La sortie pouvait être présentée comme une Master Session Key et une Extended Master Session Key venant d’EAP-PPT.

Datée du 30 septembre, la révision 04 efface cette construction. Elle indique qu’EAP-PPT ne fournit ni MSK ni EMSK et qu’une implémentation ne doit remonter aucun matériel de clé EAP-PPT à la méthode de tunnel. Supprimer cette prétention renforce la lisibilité de la sécurité : les octets ne liaient pas le porteur du jeton à la session TLS.

Le jeton au porteur n’apporte aucun secret exclusif

EAP-PPT est une méthode EAP interne. Le pair obtient un jeton Privacy Pass hors bande auprès d’un émetteur, entre dans un tunnel TLS dont le serveur est authentifié par une autre méthode EAP, puis remet le jeton au serveur EAP-PPT pour rachat.

Un jeton publiquement vérifiable est contrôlé au moyen de la clé publique de l’émetteur. Un jeton à vérification privée s’appuie sur une matière partagée entre émetteur et serveur EAP-PPT. Dans aucun cas le pair et ce serveur n’établissent un nouveau secret commun. Le pair transmet un titre au porteur ; le serveur décide si ce titre est acceptable.

L’exportateur TLS appartient, lui, à la session externe. Toute partie qui termine le tunnel peut en calculer la sortie. Comme le jeton circule à l’intérieur du même tunnel, cette partie voit aussi le jeton placé dans le contexte de dérivation. L’ajouter au contexte sépare deux calculs ; il ne crée pas une donnée inconnue du terminateur.

Une valeur peut être fraîche, propre à la session, correctement étiquetée et longue de 128 octets sans répondre à la question décisive : quel secret réservé au pair interne a contribué au résultat ? Aucun. L’apparence aléatoire ne remplace pas une contribution exclusive.

Le TLS externe ne prouve pas l’identité du pair interne

La confusion devient risquée dans TEAP. Son Crypto-Binding TLV peut combiner le matériel du tunnel et celui d’une méthode interne. Si EAP-PPT fournit comme « clé interne » une valeur entièrement calculable à partir du tunnel et d’un jeton visible par son terminateur, le calcul final ressemble à la liaison de deux preuves indépendantes. En réalité, un seul acteur possède toutes les entrées.

La révision 04 le dit sans détour : déclarer l’ancienne valeur permettrait à une méthode de tunnel de calculer un Crypto-Binding TLV sans assurer pour autant la liaison cryptographique de la méthode interne au tunnel. La séquence protocolaire dessine deux contributeurs, mais la structure des secrets n’en contient qu’un.

La nouvelle frontière est nette. EAP-PPT autorise un pair au moyen du rachat d’un jeton ; il ne fournit pas les clés de la liaison. Celles-ci viennent de la méthode EAP externe. Une console qui continue d’afficher un champ MSK ou une « clé exporter » pour EAP-PPT ne montre pas une garantie supplémentaire : elle ressuscite l’ambiguïté retirée du texte.

Une méthode interne sans clé déplace la défense contre le relais

Sans liaison cryptographique interne, la validation du certificat du serveur devient la première défense. Si un attaquant persuade le pair d’accepter son tunnel TLS, il peut relayer l’échange EAP-PPT vers un vrai service, observer le jeton au porteur et le racheter pour obtenir son propre accès.

Le projet exige donc une validation stricte et spécifique au réseau du certificat du serveur EAP. Le pair doit vérifier le nom attendu, refuser l’échec au lieu de proposer une dérogation à l’utilisateur, et ne pas fonder cette décision sur la confiance au premier usage. Lorsque origin_info figure dans le challenge Privacy Pass et correspond à l’identité du certificat, il limite la substitution du challenge. Il ne crée toutefois aucune clé interne.

L’emplacement des services compte aussi. Réunir serveur EAP et serveur EAP-PPT supprime une séparation exploitable au sein d’un fournisseur. Séparer les serveurs Phase 1 et Phase 2 n’est pas recommandé sans relation de confiance explicite et protocole interserveur protégé. Ce choix dessine une frontière de responsabilité, pas seulement une topologie.

Le channel binding peut révéler un désaccord entre le réseau que croit rejoindre le pair et l’authenticator vu par le serveur. Une vie courte limite la perte d’un jeton ; la détection de double dépense peut mettre un relais en évidence après coup. Ces mécanismes contraignent ou détectent. Ils ne transforment pas l’ancienne sortie d’exportateur en preuve de continuité du porteur.

Le jeton peut être dépensé avant le verdict de contexte

La révision 04 introduit également un ordre d’événements que les tableaux de bord ne doivent pas réduire à un simple taux de succès. Après le rachat du jeton, le serveur peut envoyer EAP-Request/PPT-Channel-Binding avant EAP Success. Il peut omettre cette demande si une méthode EAP antérieure a déjà fourni les informations requises.

Dès que le pair reçoit cette demande, il sait que le jeton a été accepté et dépensé. La suite ne l’annule pas. Une réponse mal formée, un contexte invalide, une erreur EAP ou un refus d’accès ultérieur ne rendent pas le jeton réutilisable. Les règles de nouvelle tentative applicables avant rachat cessent à cet instant.

« Jeton dépensé » est donc un reçu étroit. Il atteste un rachat réussi, pas un channel binding réussi, ni EAP Success, ni l’installation des clés externes, ni la décision RADIUS/NAS, ni le passage effectif d’un paquet.

Assimiler dépense et connexion revient à fusionner plusieurs décisions. Prétendre qu’EAP Success prouve à lui seul que la même entité détenait le jeton et terminait le tunnel reproduirait, dans un registre opérationnel, l’excès que la révision 04 vient de supprimer du calendrier de clés.

La révision 04 ne change pas seulement l’encodage

La nouvelle version remplace le contenu JSON par des TLV de style TEAP et transporte directement les structures Privacy Pass au lieu de chaînes base64url. Elle ajoute un TLV No-Suitable-Token, des règles sur les longueurs, doublons, consommation complète et imbrication unique, une politique M-bit pour les TLV inconnus et des vecteurs de test au niveau octet.

Le code d’erreur 9 distingue un message mal formé sans rachat d’un jeton bien formé qui échoue à la validation. Cette séparation décide si une nouvelle utilisation reste permise. Le texte approfondit aussi l’analyse des relais et les recommandations pour jetons publics, privés ou fédérés.

Cette précision n’est pas une preuve de déploiement. Le document est un Internet-Draft actif du groupe EMU, destiné à la voie Proposed Standard. Datatracker affiche encore I-D Exists, sans directeur de zone responsable, shepherd ni telechat. Ce n’est pas un RFC, et les sources gelées n’établissent ni implémentation, ni interopérabilité, ni performance, ni adoption.

L’exploitation doit joindre des reçus distincts

Une exploitation vérifiable conserve séparément le réseau configuré et le nom de serveur attendu ; le certificat validé, l’ancre de confiance et l’extrémité TLS réelle ; le challenge et origin_info ; le type de jeton, la clé de l’émetteur et le condensat du challenge ; le résultat et l’heure du rachat ; la provenance et le verdict du channel binding ; EAP Success ou Failure ; les clés de liaison externes ; la décision RADIUS/NAS ; et l’accès réellement observé.

Le certificat dit quel serveur le pair a accepté. Le rachat dit si le titre était valide. Le channel binding compare deux perceptions du réseau. Le résultat EAP clôt un échange. La politique NAS et le trafic montrent enfin si un accès utile a existé. Une colonne « authentifié » ne peut remplacer ces relations causales.

La leçon n’est pas que les spécifications seraient secondaires. La révision 04 est utile précisément parce qu’elle refuse de donner une autorité trompeuse à une sortie convaincante. L’exploitation réelle doit préserver les jointures que les 128 octets supprimés n’ont jamais prouvées.

Sources