Résumé

  • Dans le RFC 9987, une demande de signature apporte une clé publique, des données et des indicateurs. La réponse atteste seulement que l’agent a produit une signature ou un échec ; elle ne contient aucun champ obligatoire pour l’auteur humain, le processus, la cible ou la finalité.
  • L’interface de l’agent ne fournit elle-même ni authentification du client ni protection du transport. L’accès au point de terminaison vaut souvent capacité d’usage, et le transfert d’agent propage cette capacité sans déplacer les octets de la clé privée.
  • La confirmation, la durée de vie, le verrouillage de l’agent, l’authentification par le serveur et l’autorisation applicative sont des verdicts distincts. Daniel Kade propose un reçu d’intention en six étapes, joignable mais sans secrets.

Un succès cryptographique n’explique pas la décision

Imaginons une enquête après un accès inattendu. L’agent a répondu avec succès. La signature se vérifie. Le matériel cryptographique confirme que la clé privée n’a jamais été exportée. Le tableau de contrôle conclut alors : « usage approuvé ». C’est précisément le raccourci qu’il faut refuser. Le journal ne nomme peut-être pas le programme demandeur, ignore si l’appel venait de la machine locale ou d’un hôte auquel l’agent avait été transféré, et ne montre pas le contexte présenté au moment d’une confirmation.

Publié en mai 2026 comme norme proposée de l’IETF, le RFC 9987 formalise le protocole entre un client et un agent qui conserve des clés privées ou délègue leur usage. L’échange est conduit par le client : charger ou retirer une identité, énumérer les clés visibles, demander une signature, verrouiller l’agent ou appeler une extension. Cette portée volontairement étroite rend l’interface interopérable. Elle ne lui donne pas une connaissance générale de l’intention qui motive chaque demande.

Le message SSH_AGENTC_SIGN_REQUEST contient un blob de clé publique, une chaîne de données et des indicateurs. SSH_AGENT_SIGN_RESPONSE renvoie la signature. Aucun champ normalisé n’impose l’identité d’un exécutable, celle d’une personne, un compte distant, un nom d’hôte, une commande, un ticket ou une règle d’autorisation. Les données peuvent porter une authentification SSH, mais le protocole d’agent reste générique. Il sait quelle clé a signé quels octets ; il ne sait pas nécessairement ce que ces octets feront dans le système destinataire.

Cette limite n’est pas une faiblesse du RFC. Elle devient un défaut de gouvernance lorsqu’un autre système transforme l’observation « signature produite » en affirmation « consentement recueilli ». Pourquoi BTW Media existe demande de séparer les faits observables des récits qu’on leur superpose. Ici, le fait observable est une opération de clé. Le consentement et l’autorisation exigent leurs propres traces.

La clé peut être protégée tandis que son pouvoir est emprunté

Le RFC 9987 avertit que le protocole d’agent ne possède ni authentification intégrée du client ni sécurité de transport. Sur une machine courante, le socket local ou le canal nommé est protégé par le système d’exploitation. Quiconque atteint ce point de terminaison peut généralement demander des opérations avec les clés disponibles. La frontière décisive n’est donc pas uniquement l’endroit où réside le secret, mais la population de processus et d’hôtes autorisés à invoquer le secret.

Un composant malveillant peut échouer à extraire une clé et néanmoins utiliser un agent non contraint comme oracle de signature. La non-exportabilité réduit une classe de risque : la copie du secret. Elle ne neutralise pas l’usage volé. Pour une clé logée dans un jeton matériel, la distinction est encore plus nette. L’agent peut déléguer l’opération au jeton ; retirer l’identité de l’agent n’efface normalement pas la clé du jeton. Un compte rendu qui dit seulement « clé supprimée » mélange deux inventaires et peut clore l’incident trop tôt.

Le miroir de la politique fournit une bonne règle de lecture : chaque contrôle doit refléter l’endroit où la décision est réellement prise. Le système d’exploitation décide qui atteint le canal. L’agent décide s’il tente la signature. Le jeton décide éventuellement si une présence locale ou un code est requis. Le serveur distant décide si la clé convient au compte demandé. Puis une politique de service décide ce qu’une session authentifiée peut faire. Une signature traverse ces autorités sans les fusionner.

Une contrainte est un état daté

Le chargement contraint permet notamment une durée de vie et une confirmation explicite avant chaque opération de clé privée. Des extensions nommées peuvent ajouter d’autres limites. Si l’agent ne comprend pas une contrainte demandée, il doit refuser le chargement au lieu de l’accepter silencieusement sans protection. Ce comportement fermé est essentiel, mais il ne rend pas l’état permanent.

Le même identifiant de clé peut être ajouté de nouveau. Le RFC demande alors que les contraintes antérieures soient remplacées, à défaut de quoi l’agent peut refuser la nouvelle entrée. Une empreinte seule ne décrit donc pas l’autorité active. Il faut connaître l’époque de chargement ou de remplacement, les contraintes effectivement comprises et leur état à l’instant de l’appel. Une capture postérieure ne reconstitue pas forcément cette configuration.

La confirmation pose une autre question. Un bouton « autoriser » prouve qu’une interface a renvoyé une réponse positive. Il ne prouve un consentement éclairé que si la personne a vu une représentation sûre et exacte de la destination, du compte, du protocole et de la conséquence. Afficher les données brutes peut exposer des secrets ; afficher seulement « utiliser la clé ? » ne renseigne presque rien. Le système d’exploitation doit donc lier un résumé intelligible au hachage exact de l’opération sans copier le contenu sensible dans un journal général.

Le verrouillage de l’agent est également un état local. Tant qu’il est verrouillé, au moins les signatures de clé privée doivent être suspendues. Son déverrouillage réactive une capacité ; il n’approuve pas toute requête future et n’identifie pas les futurs demandeurs. Confondre déverrouillage et consentement global revient à donner à un geste temporaire une portée qu’il n’a jamais portée.

Le transfert est une délégation, pas un simple confort réseau

Le transfert d’agent permet à un hôte distant d’utiliser une clé locale sans en obtenir les octets privés. Cet avantage réel explique son attrait. Mais le RFC 9987 le qualifie de relation de confiance transitive, recommande qu’il ne soit pas activé par défaut et déconseille de transférer un agent vers un hôte qui n’est pas pleinement fiable. Un adversaire présent sur cet hôte peut solliciter l’agent transmis tout en laissant la clé matériellement intacte.

L’attribution rétrospective est limitée par le canal. agent-connect ne porte pas d’identifiant distinguant la session à l’origine de la connexion. Or une connexion SSH peut héberger plusieurs sessions et plusieurs flux simultanés. Savoir qu’une requête a emprunté un transport ne suffit pas toujours à la rattacher à un shell, à un processus ou à une personne déterminée.

Le code en fonctionnement d’abord rappelle que la règle écrite ne remplace pas l’observation des frontières actives. L’audit doit voir la propriété du socket, l’admission du pair, la décision de transfert, l’époque des contraintes, le moment de la demande et le verdict ultérieur du serveur. Une politique « transfert interdit » sans preuve d’exécution ne permet pas d’expliquer une signature particulière.

L’agent ne possède pas le verdict du serveur

Le RFC 4252 situe la décision d’authentification par clé publique du côté serveur. La signature couvre l’identifiant de session et des champs comprenant le nom d’utilisateur, le service, la méthode, l’algorithme et la clé publique. Le serveur vérifie la signature et décide si cette clé est acceptable pour ce compte. Il peut encore exiger un autre facteur. Le succès final est SSH_MSG_USERAUTH_SUCCESS, non la réponse antérieure de l’agent.

Le RFC 4253 fournit le transport protégé et l’identifiant de session ; le RFC 4254 régit les canaux et services qui suivent ; le RFC 4251 décrit l’architecture d’ensemble. Cette séparation technique interdit de traiter une signature comme preuve complète d’admission et, plus encore, comme autorisation de commande.

Les registres d’algorithmes ont eux aussi une portée syntaxique. Le RFC 8332 définit RSA avec SHA-2, le RFC 8709 Ed25519 et Ed448, et le RFC 8308 la négociation d’extensions. Le registre IANA des paramètres SSH permet aux implémentations de nommer les mêmes mécanismes. Une inscription au registre ne prouve ni déploiement, ni exposition d’un agent, ni consentement.

Le reçu d’intention en six étapes

Un contrôle sérieux doit relier les verdicts sans créer une nouvelle base de secrets. Première étape : l’admission du demandeur, avec chemin local ou transféré, preuve minimale du pair disponible, époque de politique et identifiant de requête. Deuxième étape : l’état de la clé, avec empreinte publique, visibilité, époque de chargement, durée de vie, confirmation, extensions, délégation éventuelle au jeton et verrouillage.

Troisième étape : l’opération, limitée à la longueur et au condensat cryptographique des données exactes, plus les indicateurs et l’algorithme. Quatrième : la confirmation, indiquant si elle était requise, quel résumé sûr a été affiché, sur quelle surface de confiance, et si le résultat fut approbation, refus ou indisponibilité. Cinquième : le verdict de l’agent, succès ou échec et classe de refus. Sixième : le résultat du système de confiance, protocole, destination, session, compte demandé, vérification, éventuel facteur supplémentaire et autorisation finale.

Ce reçu est une proposition de gouvernance de Daniel Kade, non une exigence du RFC 9987. Il n’oblige pas l’agent à comprendre la politique métier. Il empêche seulement son succès étroit de se faire passer pour toutes les décisions suivantes.

Sources