Résumé

  • Dans RFC 1509, gss_cred_id_t était une donnée atomique opaque pour l’appelant ; elle désignait un credential conservé dans GSS-API ou son mécanisme sans contenir elle-même d’information de sécurité.
  • La même valeur pouvait désigner des credentials différents pour des appelants différents. Le sens dépendait de la portée locale, de l’état de l’implémentation, du mécanisme, du principal, de l’usage et de la durée de vie.
  • Le token d’authentification voyageait vers le pair, non le handle local. Le contexte établi ne décidait toujours pas de l’autorisation applicative ni de l’effet final.

Un tiroir n’était pas contenu dans sa poignée

RFC 1509 autorisait une implémentation C à représenter un handle de credential par un pointeur ou une valeur arithmétique. La forme était modeste ; la sémantique, volontairement locale. Le texte disait que le handle ne contenait aucune information pertinente pour la sécurité et ne demandait pas à l’application de le protéger spécialement.

Surtout, deux appelants pouvaient présenter exactement la même valeur et atteindre deux credentials différents. Le handle n’était pas le credential. Il était la poignée qu’un résolveur interne interprétait dans la portée de l’appelant.

Cette formulation empêche deux conclusions opposées. Voler le nombre ne suffit pas nécessairement à voler le credential. Copier le nombre ne suffit pas non plus à transférer le pouvoir d’affirmer un principal. Il faut savoir qui appelle, quelle implémentation répond et quel état local reste derrière la référence.

La notice RFC 1509 date de septembre 1993 le Proposed Standard de John Wray et indique son remplacement par RFC 2744. Le Datatracker établit la lignée documentaire, non le comportement d’une bibliothèque ou d’un système précis.

Trois portées possibles, aucune portée universelle

RFC 1509 exigeait que l’implémentation définisse la portée des handles et des credentials. La référence pouvait être réservée au processus acquéreur, être héritée par ses enfants, ou être partagée entre des processus possédant une identité locale commune telle qu’un UID. Le credential pouvait disparaître lorsque plus aucun handle ne le rendait accessible.

Ces variantes ne changeaient pas seulement la commodité de programmation. Elles décidaient quels processus pouvaient demander qu’un principal soit affirmé.

RFC 1508, l’API abstraite, plaçait la restriction d’accès aux credentials dans les mécanismes du système et les fonctions du système d’exploitation. Le déplacement entre processus restait une affaire locale. Sa notice conserve le lien entre l’interface générique et les bindings.

RFC 1511 explique le projet du groupe Common Authentication Technology : séparer la mise en œuvre de la sécurité de l’intégration des données de sécurité dans les protocoles appelants. Sa notice relie RFC 1508, le binding C de RFC 1509, Kerberos V5 et DASS. L’abstraction devait rendre l’intégration portable ; elle ne transformait pas une référence de processus en autorité universelle.

Le défaut était une décision positive

L’appelant pouvait ne pas fournir de handle explicite et utiliser GSS_C_NO_CREDENTIAL. Malgré son nom, cette valeur ne signifiait pas forcément absence d’identité ou usage anonyme. Elle demandait à l’implémentation de sélectionner son credential par défaut.

RFC 1509 laissait l’établissement et la portée de ce défaut au système local. RFC 2078, Version 2 issue de l’expérience d’implémentation, détailla davantage la résolution du principal par défaut, les vérifications d’autorisation et les échecs possibles. Sa notice documente la révision.

Une trace contenant seulement la constante « no credential » manque donc l’événement essentiel : quel credential le système a-t-il choisi pour cet appelant à cet instant ? Il faut joindre PID, UID, compte de service, frontière d’isolation, implémentation, génération depuis le dernier redémarrage, mécanisme, principal, usage initiateur ou accepteur et expiration.

Le défaut réduit le code visible tout en augmentant la part de décision ambiante.

Un contexte pouvait durer plus longtemps qu’une connexion

RFC 1509 organisait le parcours en quatre moments : acquérir des credentials, établir un contexte commun, appliquer intégrité ou confidentialité aux messages, puis supprimer le contexte. Une session de communication pouvait traverser plusieurs connexions ; plusieurs contextes pouvaient coexister dans une même association.

gss_ctx_id_t était lui aussi relatif à l’appelant. La même valeur atomique pouvait désigner des contextes différents. Le contexte gardait un état partagé et cryptographique, mais RFC 1509 ne donnait pas d’opération permettant d’obtenir simplement un second handle vers le même contexte.

Le réseau transportait un autre objet. Le token d’authentification était une chaîne de bits protégée par le mécanisme, opaque pour l’application, produite à une extrémité pour le mécanisme pair. Les applications devaient l’insérer dans leur propre protocole.

Le handle local sélectionnait un état interne. Le token était destiné au passage entre pairs. Leur opacité commune ne leur donnait pas la même portabilité.

L’export a rendu le transfert explicite

Lorsque la Version 2 du binding C a voulu déplacer un contexte entre processus, RFC 2744 a défini export et import. L’export désactivait le contexte source, créait un token interprocessus et n’autorisait qu’une instance active. Le token pouvait contenir des clés et devait être protégé, puis confié uniquement à un processus digne de confiance. La notice RFC 2744 marque le remplacement de RFC 1509.

Cette procédure révèle ce qu’une copie de poignée ne pouvait faire : déplacer l’état, transférer éventuellement des secrets, vérifier la destination et éviter deux instances actives concurrentes.

Le cadre abstrait a continué avec RFC 2743 et sa notice. Une nouvelle version prouve l’évolution du contrat ; elle ne prouve pas que chaque produit l’a adoptée ni que l’ancienne version n’a jamais fonctionné.

Le nom affiché n’était pas le principal complet

RFC 1509 distinguait aussi le nom imprimable et le nom interne. La syntaxe d’affichage pouvait dépendre de la configuration ou des préférences. Un OID précisait l’espace de noms lors de l’import. L’égalité devait passer par gss_compare_names, non par l’égalité brute des chaînes.

RFC 2744 précise qu’un nom interne réaffiché ne doit pas nécessairement reproduire la chaîne d’origine, ni même le même identifiant d’espace de noms. Une chaîne est donc une projection produite sous un type et une configuration. Elle n’est ni le credential, ni automatiquement le compte applicatif autorisé.

La liaison de canal avait une portée bornée

Les channel bindings concaténaient types et adresses de l’initiateur et de l’accepteur avec des données d’application. Le mécanisme liait cette matière au contexte ; une divergence pouvait empêcher son établissement. Le document avertissait aussi que certaines méthodes pouvaient exposer ces données dans le token : un secret ne devait pas y être placé.

Le succès reliait un échange GSS à ces valeurs. Il ne prouvait pas la propriété juridique d’une adresse, l’autorisation d’une opération, la livraison du message ou son effet. L’appelant devait encore examiner les services demandés et retournés, le statut majeur et le statut propre au mécanisme. L’application devait ensuite décider.

Les considérations de sécurité de RFC 2744 maintiennent cette limite : GSS-API, seule, ne fournit pas une assurance universelle ; le mécanisme et la vérification correcte des indicateurs comptent.

Une interface mince exige une preuve complète

Dans Running-Code Primacy, Heng Lu replace la validité du commun dans l’exécution observée. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption conserve au niveau local les choix qui n’ont pas besoin d’être uniformes. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile refuse qu’une référence, une identité, une décision et un résultat soient traités comme le même objet.

RFC 1509 appliquait cette discipline par une API. Le contrat commun définissait les appels. L’OS et le mécanisme gardaient le credential. Le pair jugeait les tokens. L’application gardait son autorisation. Le système en marche produisait l’effet.

Les sources établissent le texte des normes et leur évolution. Elles n’établissent aucune représentation choisie par un produit nommé, aucun déploiement, incident, exploit ou comportement actuel.

La poignée pouvait rester opaque. Pour attribuer une action, la chaîne ne le pouvait pas : appelant, état local, mécanisme, principal, contexte, décision applicative et résultat devaient rester reliés.

Sources

  1. Notice RFC 1509
  2. RFC 1509 — C bindings
  3. RFC 1509 sur Datatracker
  4. Notice RFC 1508
  5. RFC 1508 — GSS-API
  6. Notice RFC 1511
  7. RFC 1511 — Common Authentication Technology Overview
  8. Notice RFC 2078
  9. RFC 2078 — GSS-API Version 2
  10. Notice RFC 2743
  11. RFC 2743 — GSS-API Version 2, Update 1
  12. Notice RFC 2744
  13. RFC 2744 — C bindings Version 2
  14. Heng Lu — Running-Code Primacy
  15. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  16. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile