Résumé

  • draft-ietf-kitten-sasl-ht-02 décrit une famille SASL à deux messages : le client prouve la possession d’un jeton éphémère, puis le serveur produit son propre HMAC afin que le client puisse authentifier le répondant.
  • La révision 02 est un Internet-Draft actif du groupe KITTEN, en dernière lecture de groupe, destiné au statut Proposed Standard et expirant le 24 décembre 2026. Ce n’est ni une RFC ni une preuve de déploiement.
  • Le HMAC du répondant établit une possession dans le sens serveur-vers-client. Il ne désigne pas, à lui seul, la génération d’état applicatif à rouvrir, le curseur à reprendre, les droits encore valables ou l’effet finalement observé.
  • Une reprise défendable relie sans les confondre l’authentification forte antérieure, l’émission du jeton, son mécanisme et sa liaison de canal, les deux HMAC, sa consommation, l’autorisation courante, la génération de session et le résultat applicatif.

Deux pairs reconnus, une mémoire encore indéterminée

Le gain promis est réel et limité. Après une authentification forte, un client reçoit un secret court et aléatoire. Si le transport tombe, il peut envoyer en un seul aller-retour une preuve calculée avec ce secret. Le serveur reconnaît le détenteur, répond avec une preuve symétrique et évite de rejouer toute la cérémonie initiale.

La continuité applicative commence là où cette mécanique s’arrête. Une session de messagerie peut contenir une position de lecture, des abonnements, des accusés de réception et une génération de file. Une console peut contenir un brouillon, un verrou ou un contexte d’administration. Aucun de ces objets n’entre automatiquement dans le HMAC SASL-HT.

La preuve couvre la chaîne littérale Initiator ou Responder, la donnée de liaison de canal choisie et les paires clé/valeur transportées par ce message. Elle ne couvre une génération de session que si l’extension applicative la place explicitement dans un champ défini, que ce champ est admis par la politique, et que le serveur vérifie ensuite l’existence et la filiation de cette génération.

Il faut donc bannir une conclusion commode : « authentification mutuelle réussie, session reprise ». La formulation exacte est plus longue mais vérifiable : les deux parties ont démontré la possession du même jeton sous le mécanisme et la liaison enregistrés ; l’application a ensuite sélectionné telle génération, appliqué telle politique et produit tel état.

Le HMAC du répondant n’est pas facultatif pour le client

Le premier message porte authcid, des valeurs optionnelles et un HMAC. Le répondant recalcule cette valeur. Si elle correspond, le projet dit que l’initiateur est authentifié ; sinon l’authentification doit échouer.

Le message final réussi commence par un octet nul, contient éventuellement des valeurs du répondant et se termine par un autre HMAC. Le client doit le vérifier pour obtenir l’authentification mutuelle. Un journal serveur ne peut donc pas prouver seul ce que le client a accepté. Une rupture après l’émission du message final laisse deux observations différentes : le serveur a produit une preuve, le client ne l’a peut-être jamais vérifiée.

Cette asymétrie devient importante lors d’un nouvel essai. Le serveur a-t-il déjà consommé le jeton ? Le client considère-t-il le premier essai comme indéterminé ? Le deuxième nœud connaît-il la consommation ? Une simple ligne « success » ne répond à aucune de ces questions. Le reçu doit distinguer calcul, émission, réception, vérification et décision applicative.

Les valeurs authentifiées gardent un sens local

Le mécanisme permet d’ajouter des paires clé/valeur aux deux messages. Leur intégrité et leur authenticité sont couvertes parce qu’elles participent au calcul du HMAC. C’est un support puissant pour transporter un hash de protection contre le downgrade ou un contexte négocié.

Mais une valeur authentifiée n’est pas une valeur autorisée. Le détenteur du jeton peut authentiquement demander une génération qui ne lui appartient plus, une option devenue interdite ou une reprise incompatible avec la version du serveur. L’application doit définir les clés, les types, les conflits, les tailles, les versions et l’autorité associée à chaque valeur.

Le point de contrôle se situe donc après la vérification cryptographique. On conserve les octets exacts et la version de schéma ; on applique la politique actuelle ; on enregistre l’admission ou le rejet ; puis on lie le choix au nouvel état. Sans cette séparation, l’extensibilité devient un moyen de faire passer une intention authentique pour une permission.

La liaison de canal est un choix, pas une propriété universelle

Le nom du mécanisme encode le hash et un type de liaison : ENDP, UNIQ, EXPR ou NONE. Les trois premiers renvoient à des constructions TLS différentes. NONE utilise une valeur vide. Un HMAC valide sous NONE ne prouve donc pas la liaison que fournirait un exporter TLS ou une autre construction.

Les tableaux de bord doivent conserver le nom complet, l’identité TLS, le type et un condensat sûr de la donnée de liaison. Afficher « lié au canal » pour tout succès HT2-* efface précisément la différence que le nom expose. Si la politique exige EXPR, la réussite de NONE demeure un rejet de politique, pas une réussite équivalente.

L’émission du jeton possède sa propre liaison. Le projet recommande que l’extension permette de déclarer le mécanisme prévu et exige l’échec si le jeton est employé avec un autre. Cette résistance au downgrade dépend d’un attribut durable dans le dossier d’émission. Si cet attribut manque ou n’est pas consulté par tous les nœuds, le nom du mécanisme observé aujourd’hui ne reconstitue pas la décision d’hier.

Le jeton bref a besoin d’un âge et d’une histoire

L’extension applicative doit produire un jeton nouvellement généré, avec au moins 128 bits d’entropie. Le projet recommande une durée limitée, par temps ou nombre d’utilisations, et le retour périodique à une authentification forte sans jeton HT.

L’entropie protège contre la devinette. Elle ne dit pas quand le jeton est né, quel compte l’a demandé, quelle authentification l’a précédé, combien de fois il a été vu ni quelles répliques l’ont invalidé. « Court » exige une horloge ; « à usage limité » exige un compteur ; « révoqué » exige une écriture convergente ; « issu après une authentification forte » exige un reçu de filiation.

Le projet précise aussi que le secret n’est ni salé ni étiré : une seule opération de hash intervient. Il ne convient pas aux mots de passe ou autres secrets partagés durables. Transformer le magasin de jetons en magasin de mots de passe n’est pas une optimisation ; c’est changer de menace sans changer de nom.

Le 0-RTT accélère une preuve rejouable

Le message initiateur peut voyager dans les données précoces de TLS 1.3. Le projet interdit alors toute charge applicative supplémentaire, hors cadrage nécessaire au profil SASL, et impose au répondant d’abandonner l’authentification si cette frontière est franchie. La raison donnée est le rejeu possible des données précoces.

Cette restriction protège la distinction la plus importante. Rejouer une preuve idempotente n’est pas répéter un achat, une suppression ou une mutation de session. Le serveur doit réserver l’usage du jeton, traiter les répétitions et attendre une autorisation ordinaire avant tout acte non idempotent. La vitesse du chemin ne crée pas l’exactement-une-fois.

La réponse peut néanmoins transporter des données applicatives après vérification de l’initiateur. Elles restent soumises au HMAC du répondant, à la vérification du client et à la politique de l’application. Le gain d’un demi aller-retour n’est donc pas un reçu de reprise ; c’est une possibilité d’ordonnancement.

La génération de session doit être nommée

Une application qui veut réellement reprendre un état doit produire un identifiant de session, une génération, un prédécesseur et une règle de conflit. Le jeton peut référencer cette lignée, mais il ne doit pas la remplacer. Un serveur qui ne retrouve pas la génération attendue doit pouvoir créer une session neuve, refuser ou demander une authentification forte sans prétendre avoir restauré l’ancienne.

Le reçu minimal lie l’identifiant non secret du jeton à son émetteur, son sujet, son service, son mécanisme, sa date, sa limite d’usage et sa génération de session. Il ajoute l’identité TLS, la liaison de canal, les condensats des deux messages, la réservation contre le rejeu, la révocation, la politique d’autorisation, la génération effectivement chargée et le résultat observé.

Cette richesse ne justifie pas de journaliser le secret, l’exporter brut ou un authentificateur réutilisable. L’objectif est de préserver les frontières de preuve sans créer une copie plus dangereuse du système d’authentification.

Sources