Résumé

  • SPAKE lie la dérivation des clés à la transcription de l’échange afin qu’un faux KDC ne puisse normalement pas vérifier un mot de passe hors ligne. L’affichage de PA-SPAKE ne prouve pas que ce parcours est arrivé à son terme.
  • Après un échec, le retour à l’horodatage chiffré peut offrir à un observateur passif de quoi tester le mot de passe saisi. Une préauthentification réussie ne vaut toujours pas autorisation applicative.

Un mécanisme de secours inspire confiance : si la voie moderne échoue, la connexion continue par une voie ancienne. Dans RFC 9588, cette continuité peut pourtant changer la nature exacte de l’attaque possible.

SPAKE vise à empêcher un adversaire actif se faisant passer pour le KDC de transformer l’échange en test hors ligne. Mais le même adversaire peut pousser le client vers l’horodatage chiffré. Si l’utilisateur s’est trompé de mot de passe avant ce repli, un tiers qui enregistre le trafic peut attaquer cette valeur hors ligne. Or une erreur humaine conserve souvent la structure du secret correct.

Le protocole plus sûr n’a pas échoué dans sa promesse. C’est la chaîne de décision qui a quitté le périmètre de cette promesse.

L’annonce n’est pas la validation

IANA enregistre PA-SPAKE sous le numéro 151. Le KDC peut annoncer le mécanisme, le client proposer ses groupes, puis le KDC en choisir un. Ces messages prouvent une négociation, pas la possession partagée de la clé dérivée.

Le début de l’échange garde des limites. Les messages de support et de défi comprennent du texte non authentifié. Sans FAST, la liste des facteurs reste visible et n’est protégée qu’après vérification de la réponse. Un PA-SPAKE-HINT se trouve hors transcription et ne remplace aucune étape.

L’achèvement arrive lorsque le KDC déchiffre la réponse, valide les facteurs requis et que les deux parties renforcent la clé de réponse avec K'[0]. Aucun dernier message PA-SPAKE n’est envoyé par le KDC ; l’authentification du KDC reste liée à la réponse KDC chiffrée.

Le repli choisit une autre exposition

RFC 9588 recommande que le client puisse désactiver l’horodatage chiffré par realm. La mesure est plus exigeante qu’un inventaire « compatible SPAKE ». Un parc peut annoncer le nouveau protocole partout et conserver l’ancienne faiblesse dans sa logique de récupération.

SPAKE ne bloque pas non plus les essais en ligne. Le KDC voit les échecs et peut limiter leur fréquence. Un tableau ne comptant que les échanges SPAKE réussis ignore donc les replis, les tentatives en ligne et les décisions de limitation — précisément les branches qui définissent le risque résiduel.

Le ticket et le droit restent séparés

Un échange réussi prouve la connaissance de la clé initiale et, le cas échéant, la validation du facteur choisi. SF-NONE signifie explicitement qu’aucun second facteur n’est utilisé : SPAKE n’est pas automatiquement du MFA.

Il faut encore recevoir et authentifier la réponse du KDC, obtenir un ticket, le présenter au service, puis satisfaire la politique d’autorisation de l’application. L’intégrité de la requête Kerberos ne crée pas un rôle applicatif et ne prouve pas qu’une ressource a été livrée.

Les détails d’implémentation restent décisifs : points valides, scalaires uniformes et non réutilisés, absence de logarithme discret connu pour les points de masque, exécution sans fuite temporelle. Pour un KDC sans état, PA-FX-COOKIE doit être confidentiel, intègre, limité dans le temps et lié au principal ; sinon sa relecture peut faire apparaître un client comme authentifié. Enfin, le RFC précise que SPAKE n’a pas été conçu pour garantir la confidentialité persistante.

Sources