Résumé

  • Le projet draft-ietf-tls-pake-02 associe un secret issu d’un PAKE à l’échange de clés TLS, mais le serveur ne peut considérer le client authentifié qu’après validation du Finished envoyé par celui-ci.
  • Le choix d’un schéma, l’existence d’un enregistrement, l’identité PAKE, le certificat, l’autorisation métier et la résistance future du mot de passe restent des preuves distinctes.

Le serveur avait déjà envoyé son ServerHello, choisi un schéma PAKE et calculé les secrets de trafic. Il transmit alors le profil du compte. Quelques millisecondes plus tard, le Finished du client échoua.

Les octets avaient été livrés à une partie que le serveur n’avait jamais authentifiée.

La révision 02 de A Password Authenticated Key Exchange Extension for TLS 1.3 décrit un moyen d’utiliser un secret de faible entropie sans le placer directement dans le mécanisme PSK de TLS 1.3. Publiée le 6 juillet 2026 et valable jusqu’au 7 janvier 2027, elle demeure un Internet-Draft actif du groupe TLS. Elle n’est ni RFC, ni registre achevé, ni preuve d’implémentation. Le texte prévient même que son analyse de sécurité reste incomplète.

Un mot de passe ne devient pas une clé à haute entropie

Le binder d’un PSK TLS permettrait de tester hors ligne les candidats si le secret partagé était simplement un mot de passe humain. Le projet transporte donc des messages PAKE dans une extension dédiée et injecte le secret obtenu dans le calendrier de clés avec l’échange éphémère ordinaire.

Le client doit toujours offrir supported_groups et key_share. Le mot de passe n’efface ni le besoin de confidentialité persistante ni celui d’un échange éphémère. Les offres PAKE sont triées et uniques, tandis qu’une seule paire d’identités client/serveur couvre toutes les offres.

Cette mécanique produit plusieurs étapes observables : offre de schémas, sélection commune, recherche de l’enregistrement, message du serveur, calcul du secret, Finished du serveur, Finished du client. Une métrique qui transforme la sélection en succès d’authentification saute précisément les étapes où une simulation ou un mauvais mot de passe doit échouer.

Le serveur peut simuler un compte absent

Lorsque la paire d’identités ne correspond à aucun enregistrement valide, le serveur peut fabriquer un partage PAKE plausible et poursuivre. Le client ne possède pas le secret correspondant ; son Finished sera donc rejeté avec une probabilité écrasante.

Cette simulation évite que le premier vol serveur serve d’annuaire des comptes. Elle signifie aussi qu’un ServerHello contenant l’extension n’atteste pas l’existence du compte. Il atteste seulement que le serveur a choisi de suivre une branche compatible, réelle ou simulée.

L’indistinguabilité ne se limite pas au contenu du paquet. Le temps de réponse, l’alerte finale, la consommation CPU, les accès au stockage, les journaux et les quotas peuvent révéler le résultat de la recherche. Le projet fournit une construction protocolaire ; il ne certifie pas que chaque mise en œuvre garde tous ces canaux alignés.

Finished est le point de contrôle du client

Le secret PAKE et le secret (EC)DHE alimentent ensemble le calendrier TLS. Le transcript inclut les messages PAKE. Le Finished du client démontre alors qu’il a obtenu la matière cryptographique correcte pour ce transcript.

Avant cette validation, le serveur ne doit pas traiter le client comme authentifié. Le projet recommande de ne pas envoyer de données applicatives. Cela concerne plus que des secrets évidents : un identifiant de compte, une liste de droits, une personnalisation ou une différence de taille peut confirmer l’existence d’un utilisateur.

Après Finished, la preuve reste bornée. Elle ne dit pas qui a effectué l’enregistrement initial, si l’appareil est intègre, si le compte est suspendu, ni si l’action demandée est autorisée. Le protocole prouve la possession nécessaire à une session ; l’application doit encore rendre sa décision.

Le journal utile comporte donc deux horloges : instant de validation du Finished client et instant de première donnée applicative. Si la seconde précède la première, la faille est mesurable sans prétendre que le PAKE lui-même est cassé.

Trois identités peuvent coexister

L’server_identity du PAKE est distinct du SNI. Le premier appartient au contexte du secret et de l’enregistrement ; le second contribue au routage et à la sélection du service. Un certificat peut ajouter une troisième identité de référence.

Si le client envoie signature_algorithms avec PAKE, le serveur sélectionnant PAKE doit aussi fournir Certificate et CertificateVerify. Ce mode cumule deux preuves. Sans cette demande, la connaissance du mot de passe peut servir à authentifier la relation sans la même preuve PKI.

Il faut inscrire le mode exact dans le reçu. « TLS mutuellement authentifié » ne précise pas si le nom DNS a été validé, si le serveur PAKE attendu a répondu, ou si les deux conditions étaient requises. Une réussite cryptographique ne résout pas un conflit entre ces espaces de noms.

Le PAKE externe déplace la jointure

Les PAKE internes tiennent en deux messages intégrés aux Hello. Un protocole nécessitant davantage d’allers-retours s’exécute hors TLS, puis son résultat est importé comme PSK suivant RFC 9258.

Le succès du second échange prouve que les deux extrémités possèdent la clé importée. Il ne prouve pas à lui seul que l’échange externe concernait les bonnes identités, qu’il a été relié au bon canal ou que sa sortie n’a pas été réutilisée ailleurs.

RFC 9258 sépare les clés par protocole, KDF et contexte et demande un channel binding vers le protocole producteur. Encore faut-il que l’application fournisse et conserve ce contexte correctement. Sans hash du transcript externe, identité importée et identifiant de connexion consommateur, l’audit ne possède que la moitié finale de la chaîne.

Le trafic post-quantique ne protège pas forcément le mot de passe

Un échange TLS hybride ou post-quantique peut empêcher qu’un enregistrement du trafic soit déchiffré plus tard. Si le PAKE reste classique, son propre transcript peut néanmoins devenir vulnérable à un ordinateur quantique futur.

Le risque n’est pas seulement la lecture du passé. Un mot de passe humain réutilisé, récupéré rétroactivement, autorise des usurpations futures jusqu’à sa rotation. La confidentialité des données et la durée de sûreté du justificatif ont donc des horizons différents.

Le projet décrit des options OQUAKE et OQUAKE+ et renvoie à un PAKE hybride externe. Ces constructions dépendent encore de documents de recherche actifs. Elles doivent être suivies comme des choix de conception en évolution, non comme une certification disponible.

L’enregistrement précède le protocole

Le serveur possède déjà des enregistrements dérivés du mot de passe, des identités, des paramètres et parfois des sels. La façon dont ils ont été créés, réinitialisés, migrés ou révoqués sort du champ du projet.

Un Finished valide peut donc reposer sur un mauvais acte administratif : récupération attribuée au mauvais titulaire, ancien vérificateur encore actif, schéma migré sans destruction ou identité PAKE reliée au mauvais compte métier.

L’autorité chargée de l’enregistrement, celle qui exploite TLS et celle qui accorde le droit applicatif peuvent être trois équipes. Leur fusion dans un unique indicateur « authentifié » masque qui pouvait prévenir l’erreur.

Une poignée de main est une suite de promesses limitées

Le PAKE offre une amélioration réelle : le mot de passe n’est pas utilisé comme PSK brut et le serveur peut éviter une énumération triviale. Mais sa sécurité opérationnelle dépend du respect des étapes négatives, notamment du droit de simuler et d’échouer tard.

La sélection prouve la compatibilité. La simulation protège l’existence du compte. Finished prouve la possession liée au transcript. Le certificat, lorsqu’il est requis, prouve une autre identité. L’autorisation et le résultat appartiennent ensuite à l’application.

La bonne décision de direction n’est pas d’exiger un voyant PAKE vert. C’est d’empêcher toute donnée, tout privilège et toute affirmation d’identité de franchir la frontière avant que la preuve correspondante n’existe.

Sources