Résumé

  • Lorsqu’un échange comporte une réponse, RFC 2025 forme le Context ID en concaténant le randSrc de l’initiateur et le randTarg de la cible. Chacun a alors contribué à distinguer le nouveau contexte des anciens.
  • Le SPKM-2 unilatéral se limite à SPKM-REQ. La cible ne fournit aucun aléa : elle doit se fier à la fraîcheur annoncée par l’initiateur ou refuser le contexte. key-src-bind renforce une liaison, mais ne crée pas une contribution de la cible.
  • La protection contre la répétition lors de l’établissement et les services optionnels de replay/séquençage pour les messages ultérieurs relèvent de deux plans distincts. Le Context ID ne prouve ni autorisation, ni livraison, ni résultat métier.

Un identifiant dont on peut compter les auteurs

Le Simple Public-Key GSS-API Mechanism défini par RFC 2025 utilise plusieurs jetons pour établir un contexte de sécurité. Parmi leurs nombreux champs, la construction du Context ID donne une indication remarquablement précise. L’initiateur envoie randSrc. Si l’échange prévoit une réponse, la cible y ajoute randTarg. La concaténation, dans cet ordre, devient l’identifiant employé dans les jetons suivants du contexte.

Cette structure rend la provenance visible. Avec les deux valeurs, l’initiateur sait que la cible a produit un élément pour cet échange précis. La cible, elle, sait que sa propre valeur neuve a été incorporée avec celle de l’initiateur. randSrc || randTarg fonctionne donc comme un reçu bilatéral, mais uniquement pour une affirmation limitée : ce contexte est séparé des anciens avec une forte probabilité.

RFC 2025 ne demande pas que ces valeurs soient imprévisibles. Elles doivent surtout avoir une probabilité très élevée de ne jamais avoir été utilisées. Leur fonction est la non-répétition entre contextes, pas le secret. Une valeur dite « plus aléatoire » n’étend pas la portée de la preuve.

L’échange sans réponse

SPKM-1 obtient toujours une réponse de la cible. Sa forme unilatérale emploie SPKM-REQ puis SPKM-REP-TI; sa forme mutuelle ajoute SPKM-REP-IT. SPKM-2 mutuel comporte lui aussi une réponse. Dans chacun de ces cas, la cible dispose d’un jeton pour fournir randTarg.

SPKM-2 unilatéral rompt cette symétrie. Il ne contient que SPKM-REQ. Aucun jeton de retour ne permet à la cible d’ajouter son aléa, de sorte que le Context ID se réduit à la valeur de l’initiateur. Le texte impose alors une alternative à la cible : faire confiance à l’initiateur pour la fraîcheur de cet aléa, ou refuser le contexte.

Il ne s’agit donc pas d’une simple économie d’aller-retour. L’acteur qui décide d’accepter le contexte perd la possibilité d’y inscrire sa propre contribution de non-réutilisation. Le Context ID continue d’identifier le contexte, mais ne témoigne plus d’une production conjointe de sa fraîcheur.

key-src-bind n’est pas une réponse cachée

Le mécanisme prévoit une protection particulière pour ce cas. Si l’algorithme d’établissement de clé ne lie pas lui-même le nom de la source à la clé de contexte, SPKM-REQ doit contenir key-src-bind, un condensat MD5 du nom source encodé et de la clé proposée.

Cette valeur aide la cible à vérifier que le nom revendiqué, le jeton reçu et la clé proposée appartiennent à la même demande. RFC 2025 explique aussi qu’elle contribue à la confiance de la cible dans la fraîcheur du jeton et de la clé. Elle demeure néanmoins produite dans la requête de l’initiateur. Elle n’ajoute ni réponse, ni randTarg, ni matière fraîche générée par la cible.

La liaison d’identité à une clé, la provenance de la fraîcheur et l’authentification mutuelle sont trois faits différents. Une base de données qui les résume par un seul état « contexte établi » efface une différence que le protocole avait précisément rendue observable.

Deux plans de lutte contre la répétition

SPKM peut également contrôler la répétition et l’ordre des messages protégés après l’établissement. Ces services utilisent des numéros de séquence lorsque l’application les demande. Ils ne découlent pas automatiquement des aléas du Context ID.

La spécification générale de GSS-API, RFC 2743, traite replay et sequence comme des options par message du contexte. L’appelant les sollicite, l’accepteur indique ce qui est disponible, et une implémentation peut signaler un doublon ou un désordre par un statut supplémentaire tout en remettant le message à l’appelant. Le transport des jetons reste du ressort de l’application.

Une preuve correcte doit donc répondre séparément à deux questions : cette tentative d’établissement a-t-elle été distinguée d’une ancienne tentative ? Les messages ultérieurs ont-ils fait l’objet d’un contrôle des doublons ou de l’ordre dans le contexte accepté ? Le Context ID éclaire la première; les drapeaux négociés, l’état des séquences et les résultats de vérification éclairent la seconde.

Une trace historique, pas une preuve de déploiement

Le RFC Editor répertorie RFC 2025 comme Proposed Standard publié en octobre 1996; la recherche d’errata ne faisait apparaître aucun erratum publié lors de cette analyse. Le registre SMI de l’IANA conserve les identifiants d’objet de SPKM-1, SPKM-2, SPKM-3 et de l’arc des jetons SPKM GSS. Ces éléments documentent une normalisation et une attribution de numéros, pas un usage contemporain.

RFC 2847 a ensuite défini SPKM-3 comme équivalent à SPKM-1, hormis des modifications expressément indiquées. Cette filiation aide à situer la famille, sans modifier la limite probatoire de RFC 2025 : un Context ID ne se lit correctement qu’avec le schéma d’échange qui l’a produit.

La conclusion tient en deux lignes. randSrc || randTarg enregistre une contribution bilatérale à la fraîcheur du contexte. Dans SPKM-2 unilatéral, le Context ID n’enregistre que celle de l’initiateur, même avec key-src-bind. Aucun des deux ne certifie à lui seul une autorisation, un choix d’algorithme, la livraison d’un message ou l’achèvement d’une opération.

Sources