RFC 9644 : de l’algorithme autorisé à la preuve de session SSH

Résumé

• La RFC 9644 normalise la représentation YANG des capacités et des préférences d’algorithmes SSH, mais ne fournit pas un journal de négociation par session.
• Une attestation solide relie la révision du registre, les capacités de l’implémentation, les listes ordonnées approuvées, les deux offres SSH_MSG_KEXINIT, les choix dans chaque sens, la clé d’hôte, NEWKEYS, l’authentification et l’opération applicative.
• Ce reçu constitue une règle d’exploitation proposée, non une obligation de la RFC ; une observation manquante doit réduire la portée de la conclusion.

Trois autorités, aucune preuve complète

La scène paraît banale : après une opération de durcissement, le comité de changement reçoit la liste des algorithmes autorisés, la confirmation que l’équipement accepte la configuration et un écran indiquant « pris en charge ». Chacun de ces éléments répond à une question légitime. Aucun ne répond à la question finale : quels algorithmes ont protégé la connexion utilisée, avec quel interlocuteur, pour quel résultat ?

La RFC 9644 définit les groupements génériques ietf-ssh-common, ietf-ssh-client et ietf-ssh-server. Elle prévoit aussi la génération de quatre modules d’énumération à partir des registres SSH maintenus par l’IANA. Le bénéfice est réel : contrôleurs et équipements peuvent partager un vocabulaire sans que chaque fournisseur reconstruise sa propre taxonomie.

Mais ce vocabulaire n’est qu’une couche d’autorité. L’IANA administre l’identifiant ; l’implémentation déclare une capacité ; l’organisation fixe une permission ; les deux pairs produisent un choix au cours de l’échange. Prendre l’une de ces couches pour une autre revient à faire d’un symbole la preuve d’un événement.

Le registre ne vote pas la politique de sécurité

Les modules générés suivent les registres sources : une évolution ajoute une révision, les valeurs réservées ou non attribuées sont écartées et les statuts pertinents sont conservés. Cette mécanique permet d’identifier précisément le vocabulaire compris lors d’une configuration.

Elle ne transforme pas un enregistrement en recommandation. Les registres accueillent des identifiants d’époques et de statuts différents. La RFC 9142 montre d’ailleurs que les niveaux de recommandation des méthodes d’échange de clés peuvent évoluer. Une preuve de gouvernance doit donc conserver deux décisions séparées : quel instantané du registre et quelle révision YANG étaient en vigueur ; puis quel sous-ensemble l’autorité locale a autorisé, refusé ou placé en dernier recours.

Sans le premier élément, on ne sait pas exactement quel dictionnaire était partagé. Sans le second, on attribue à l’IANA une décision de risque qu’elle n’a pas prise.

Une capacité déclarée reste une possibilité

Lorsque la fonctionnalité optionnelle algorithm-discovery est présente, supported-algorithms expose des données opérationnelles en config false. Ce relevé aide à préparer une migration : il indique ce que l’implémentation affirme savoir exécuter pour l’échange de clés, la clé d’hôte, le chiffrement ou l’intégrité.

Il ne prouve ni l’autorisation ni l’usage. Un algorithme peut être compilé mais interdit par la politique. Il peut être autorisé mais perdre la négociation face à un choix mieux classé. Il peut ne jamais rencontrer un pair compatible. La mesure doit en outre être datée et liée à une version logicielle, à ses fonctionnalités et à ses éventuelles déviations YANG.

Le cas de la liste absente est encore plus révélateur. La RFC 9644 laisse alors l’ensemble acceptable à l’implémentation. Une interface qui affiche une case vide comme un « défaut sûr » invente une garantie universelle. La conclusion correcte est soit la description vérifiée du comportement effectif de ce produit, soit l’aveu que l’ensemble permis n’a pas été établi.

L’ordre de la politique rencontre l’offre du pair

Dans transport-params-grouping, les listes de méthodes d’échange, d’algorithmes de clé d’hôte, de chiffrement et de MAC sont ordonnées par préférence décroissante. Cet ordre doit rester intact dans l’audit : le trier alphabétiquement effacerait la décision.

La RFC 4253 place ensuite la décision dans l’échange. Chaque pair émet des listes dans SSH_MSG_KEXINIT. Pour les méthodes d’échange et la clé d’hôte, le choix suit la préférence du client parmi les valeurs également offertes par le serveur, sous réserve des capacités exigées par la méthode. Pour le chiffrement et le MAC, les choix sont distincts du client vers le serveur et du serveur vers le client.

Cette directionnalité interdit le résumé « chiffrement conforme » dépourvu de sens de circulation. Elle impose de conserver les deux offres et les valeurs retenues. Sans intersection acceptable, la connexion s’arrête : l’acceptation préalable de la configuration ne préjugeait donc pas du fonctionnement.

L’algorithme de clé d’hôte n’est pas l’identité de l’hôte

Le nom négocié décrit une procédure cryptographique. Il reste à savoir quelle clé le serveur a effectivement présentée et sur quelle base le client l’a acceptée. La RFC 8332 fournit un exemple décisif : un même format de clé publique RSA peut servir à des algorithmes de signature SHA-2 différents. La présence d’une clé RSA ne permet pas de reconstruire le choix.

La RFC 9644 sépare justement l’identité du client et les paramètres d’authentification du serveur, avec des références possibles aux magasins de clés et de confiance. Cette séparation évite plusieurs raccourcis : algorithme permis ne signifie pas clé attendue ; clé connue ne signifie pas signature conforme à la politique ; serveur reconnu ne signifie pas utilisateur authentifié ; utilisateur authentifié ne signifie pas opération autorisée.

Le reçu doit donc distinguer l’algorithme, l’empreinte de la clé présentée, la règle de validation, son résultat et les limites d’observation. Un capteur réseau peut voir une négociation sans connaître la décision de confiance prise dans le client. Il doit alors laisser ce champ inconnu au lieu de le déduire.

La frontière NEWKEYS

SSH_MSG_NEWKEYS marque l’activation des clés et algorithmes nouvellement calculés. Deux offres compatibles ne suffisent pas si la transition n’aboutit pas. Et cette transition ne clôt pas la chaîne : le protocole d’authentification de la RFC 4252 intervient ensuite, avant l’autorisation et le résultat applicatif.

Un reçu opérationnel minimal peut relier :

• l’instantané IANA et la révision ou l’empreinte des modules générés ;
• l’identité de l’implémentation, ses fonctionnalités et déviations ;
• l’observation datée des capacités ;
• la révision de configuration, l’approbateur et les listes dans leur ordre exact ;
• les empreintes ou captures protégées des deux messages KEXINIT ;
• les choix d’échange, de clé d’hôte, de chiffrement et de MAC dans chaque sens ;
• l’empreinte de la clé d’hôte et la décision de confiance ;
• l’achèvement de NEWKEYS ;
• la méthode et le résultat d’authentification, sans révéler de secret ;
• l’opération applicative, son critère d’acceptation et son résultat.

Aucune source citée n’impose ce format unifié. C’est un dispositif de contrôle construit aux frontières laissées entre modèle, protocole et application.

La formulation minimale qui résiste à l’audit

Le principe de spécification initiale minimale de Heng Lu invite à choisir d’abord la phrase que le système devra réellement prouver. « Le SSH est sécurisé » est trop vaste. Une formulation exploitable serait : pour telle opération, dans telle fenêtre temporelle, la politique approuvée peut être reliée aux choix observés, au pair validé et au résultat attendu.

La primauté du code en fonctionnement fixe ensuite l’arbitrage. Le registre et le modèle organisent le plan symbolique ; l’échange exécuté borne le récit de ce qui s’est produit. En cas d’écart, l’observation gouverne la conclusion sur la session, et l’écart devient un incident de contrôle.

Ainsi, une configuration seule autorise à dire « la politique a été acceptée ». KEXINIT et NEWKEYS sans visibilité sur la confiance autorisent à parler des algorithmes activés, pas de l’identité. Une identité validée sans résultat applicatif ne prouve pas la livraison du service. La qualité de l’attestation tient moins à sa longueur qu’à sa capacité à s’arrêter exactement où s’arrête la preuve.

Sources

1. Spécification initiale minimale
2. Couches de réalité et pouvoir symbolique
3. Primauté du code en fonctionnement
4. Dossier Datatracker de la RFC 9644
5. Fiche d’information de la RFC 9644
6. RFC 9644 en HTML
7. RFC 9644 en texte brut
8. RFC 9644 en XML
9. Errata intégrés de la RFC 9644
10. Paramètres IANA du protocole SSH
11. Paramètres YANG de l’IANA
12. RFC 4250 : numéros attribués à SSH
13. RFC 4252 : authentification SSH
14. RFC 4253 : couche transport SSH
15. RFC 6187 : certificats X.509v3 pour SSH
16. RFC 8332 : clés RSA et signatures SHA-2
17. RFC 9142 : évolution des méthodes d’échange SSH
18. RFC 7950 : YANG 1.1
19. RFC 8341 : contrôle d’accès à la configuration
20. RFC 8342 : architecture des datastores de gestion