Résumé

  • Dans RFC 9594, le serveur d’autorisation permet à un Client d’accéder à une ressource d’adhésion ; seul l’échange Join réussi auprès du KDC crée le membre et lui remet l’état défini par le profil applicatif.
  • Jeton valide, inscription du membre, version de clé reçue et communication de groupe réussie sont des faits séparés, détenus par des acteurs différents.

Imaginons un tableau de contrôle où le jeton est signé, le rôle demandé est permis et la durée de validité n’a pas expiré. Il est tentant d’afficher « membre actif ». Pourtant, à cet instant, le Client peut ne jamais avoir parlé au KDC. Il peut avoir transmis le jeton sans établir l’association sécurisée. Sa demande Join peut avoir échoué. Il peut avoir reçu une réponse sans installer la clé.

RFC 9594 transforme cette liste d’incertitudes en architecture. Le texte sépare expressément deux phases : l’autorisation ACE entre Client, serveur d’autorisation et KDC, puis la distribution effective des éléments de clé entre le Client et le KDC. La seconde phase n’est pas une simple conséquence administrative de la première.

Le serveur d’autorisation permet de demander

Le serveur d’autorisation applique une politique. Il détermine si le Client peut atteindre une ou plusieurs ressources d’adhésion et avec quels rôles. Le jeton obtenu est ensuite transféré au KDC, généralement via /authz-info. Le Client et le KDC doivent communiquer selon le profil de transport ACE choisi, par exemple DTLS ou OSCORE.

Ce parcours établit une permission et un canal. Il n’établit pas encore l’adhésion. Le Client doit envoyer une requête à /ace-group/GROUPNAME. Le KDC vérifie le jeton stocké, le groupe visé, les rôles, les éléments de preuve et les exigences du profil applicatif. C’est seulement après ces contrôles que le gestionnaire Join ajoute le Client à la liste des membres courants et retourne le matériel nécessaire.

La limite de preuve est nette. Le serveur d’autorisation peut attester sa décision. Il ne peut pas attester que le KDC a accepté la demande. Le KDC peut attester l’admission et la version distribuée. Il ne peut pas attester que le Client l’a installée. L’interface devrait conserver cette modestie au lieu de faire d’un jeton le substitut de toute la chaîne.

Un chemin stable ne signifie pas un état stable

RFC 9594 définit une surface persistante. La ressource /ace-group/GROUPNAME représente l’adhésion au groupe ; des ressources sous /nodes/NODENAME représentent les membres. Le nom du groupe et le nom du nœud restent invariants une fois établis. Cette stabilité facilite les opérations et la référence.

Mais l’état cryptographique peut changer derrière ces noms. Le paramètre num identifie la version courante du matériel de groupe. Les identifiants cryptographiques, les informations individuelles, les justificatifs des pairs et les politiques appartiennent au profil et à l’époque courante. Une URL stable prouve l’identité de la ressource, pas la fraîcheur de ce qu’un Client détient.

Cette distinction explique l’importance de relier les justificatifs à une version. L’erratum technique 8239, encore signalé comme « reported » lors de la recherche, ajoute num à un exemple de récupération des justificatifs où ce champ requis manquait. L’erratum 8864 corrige la description de filtres vides. Ce sont des dossiers de maintenance de la spécification, non la preuve d’une faille chez un opérateur. Leur intérêt est méthodologique : une liste de justificatifs sans contexte de version est une preuve incomplète.

Le profil applicatif complète le contrat

Le RFC de base n’impose pas une seule méthode de communication sécurisée. Il fournit l’interface KDC, des structures CBOR communes, un type de média et des registres IANA. Il demande ensuite à chaque profil applicatif de préciser ce que l’interopérabilité exige réellement : type et format de clé, identifiants, justificatifs, preuve de possession, politiques, protection du rekeying, ressources prises en charge et capacités minimales du Client.

Le paramètre de profil et l’enregistrement IANA nomment ce contrat. Ils ne le remplacent pas. Afficher « conforme RFC 9594 » sans indiquer le profil, sa version et les choix appliqués confond une enveloppe commune avec une implémentation achevée.

C’est une application saine du principe de spécification initiale minimale : mettre dans la couche commune ce qui doit être commun, laisser au profil les décisions spécialisées et rendre ces décisions vérifiables. Le risque apparaît lorsque la délégation devient invisible et que l’étiquette du RFC absorbe des choix qu’il n’a jamais tranchés.

Une nouvelle version peut diviser momentanément le groupe

Les clés expirent. Elles peuvent être renouvelées périodiquement, et un changement de membres peut déclencher un renouvellement. La sécurité rétroactive peut exiger une nouvelle clé à l’arrivée d’un membre ; la sécurité prospective peut l’exiger lors d’un départ ou d’une expulsion.

Le KDC incrémente NUM avant de distribuer NUM+1. Plusieurs messages peuvent être nécessaires. Pendant ce temps, certains membres disposent du nouvel état et d’autres de l’ancien. RFC 9594 reconnaît cette désynchronisation temporaire. Une fois le rekeying terminé, l’ancien matériel est supprimé et le nouveau devrait être conservé de manière persistante.

Cette analyse ne reprend pas la thèse distincte de l’article consacré à RFC 9838 et à la séquence KEK–TEK d’exclusion. Elle retient seulement la limite propre à RFC 9594 : la décision du KDC et l’incrément d’une version ne prouvent pas une installation simultanée chez tous les membres. Il faut des reçus de distribution, de vérification et d’activation.

Le Dispatcher transporte sans devenir autorité

Une fois admis, les Clients peuvent communiquer via un Dispatcher. En multidiffusion, cette fonction est implicite ; dans un système publication-abonnement ou avec relais, elle peut être un intermédiaire explicite. Le RFC précise qu’un Dispatcher explicite peut voir et acheminer les messages protégés, mais ne possède pas le matériel de clé du groupe.

Sa position dans le trajet ne lui donne donc pas le pouvoir de certifier les membres. Un courtier peut transmettre sans lire. Un relais peut atteindre plusieurs destinations sans savoir si elles partagent NUM. Le présent rapport s’arrête avant la question, déjà traitée pour RFC 10020, de savoir si un message protégé a produit une action locale. Ici, il faut d’abord prouver que la permission s’est changée en adhésion, puis en état installé.

Le registre de transition ne doit jamais contenir la clé

Un audit utile conserve l’identifiant ou le condensat du jeton, l’émetteur, l’audience, la portée, les rôles et l’expiration ; le résultat du transfert au KDC ; le profil de transport ; l’identifiant de la demande Join ; GROUPNAME et NODENAME ; le profil applicatif ; num ; les résultats de preuve de possession et de vérification ; l’installation locale ; les versions de politiques et de justificatifs ; les heures de rekeying ; et la dernière utilisation confirmée. Il ne journalise jamais le secret lui-même.

Chaque preuve reste sous la garde de son observateur. L’AS atteste sa politique. Le KDC atteste l’admission et la distribution. Le Client atteste la vérification et l’installation. Le Dispatcher atteste l’acheminement. L’application atteste l’effet. Cette séparation met en pratique les couches de réalité décrites par Lu Heng : un document d’autorité peut décrire une décision sans créer les faits d’exécution qui la suivent.

Sources