Résumé

  • RFC 9918 maintient l’authentification mutuelle de NETCONF sur TLS et recommande que les AC approuvées ne délivrent des certificats qu’aux parties autorisées à accéder aux serveurs NETCONF.
  • La liste ordonnée de RFC 7589 peut faire correspondre l’empreinte du certificat présenté ou celle d’une AC de sa chaîne, puis dériver un nom d’utilisateur NETCONF selon un type de mappage.
  • Une chaîne valide et un nom dérivé ne prouvent ni l’autorisation NACM d’une opération, ni son commit, ni sa réalisation par l’équipement.

La chaîne ne porte pas le motif de délivrance

La validation PKIX établit qu’une chaîne respecte les entrées retenues : ancre de confiance, politiques, période de validité, contraintes et état de révocation. Elle ne convertit pas chaque certificat descendant en badge d’administration réseau.

RFC 9918 formule le risque sans détour. Lorsqu’un déploiement s’appuie sur une liste d’AC approuvées, ces AC devraient réserver leurs certificats aux parties autorisées à accéder à NETCONF. Si elles signent aussi pour d’autres finalités, les certificats correspondants peuvent être acceptés à tort par le serveur NETCONF.

La cryptographie peut donc fonctionner exactement comme prévu pendant que la frontière métier échoue. L’émetteur est bien celui attendu ; la finalité ne l’est pas. L’erreur consiste à confondre l’ensemble « certificats sous cette AC » avec l’ensemble plus petit « identités habilitées pour ce plan de contrôle ».

TLS 1.3 ne supprime pas cet écart. RFC 9918 impose toujours TLS 1.2 mutuellement authentifié, recommande TLS 1.3, exige de le préférer lorsqu’il est disponible et interdit les données précoces. Il précise pourtant que les règles de validation et d’identité de RFC 7589 restent inchangées.

Une liste ordonnée fabrique l’identité applicative

Après la validation, RFC 7589 utilise une liste ordonnée de correspondances. Une entrée peut viser l’empreinte du certificat client ou celle d’une AC ayant participé à sa chaîne. Le type de l’entrée choisit ensuite un nom configuré, un rfc822Name, un dNSName, une adresse IP ou, sur une voie déconseillée, le CommonName.

Trois verdicts doivent rester visibles : la chaîne est-elle valide ? Une entrée correspond-elle ? Cette entrée produit-elle un nom d’utilisateur NETCONF valable ? Si le champ demandé manque ou si le nom est invalide, le serveur poursuit avec les entrées suivantes ; sans résultat exploitable, il ferme la session.

L’ordre n’est donc pas cosmétique. Une règle d’AC très générale placée avant une règle de certificat précis peut changer le nom obtenu sans modifier aucun octet du certificat. Une modification de san-any vers un nom explicite peut faire de même. RFC 7407 rend cette logique configurable, donc auditable — à condition de conserver version et ordre.

Le nom de service ne décide pas le droit d’agir

RFC 9525 demande au client de construire ses identifiants de référence indépendamment du certificat présenté par le serveur, puis de chercher une correspondance. C’est une preuve ciblée de l’identité du service, complétée par les vérifications de validité et de révocation.

Le côté client ne se déduit pas par symétrie. La validité de sa chaîne est une preuve PKI. Le nom NETCONF issu de la table est une identité applicative. Les permissions de ce nom sont une décision locale. RFC 6241 exige que ces permissions soient connues et appliquées pendant la session ; RFC 8341 NACM limite séparément opérations, données, actions et notifications.

Viennent encore la réponse RPC, le datastore visé, le commit éventuel, la lecture de contrôle et l’effet sur l’équipement. Une réponse positive à <edit-config> ne certifie pas nécessairement un commit ; un commit ne certifie pas le comportement du réseau ; une lecture de configuration n’est pas une mesure de service.

Un reçu qui permet de rejouer l’admission

Le reçu utile conserve les empreintes de la feuille et de la chaîne, l’heure de validation, l’ancre, les politiques et la révocation ; l’identité serveur attendue ; la version de la table de mappage ; l’entrée gagnante et sa position ; le type de correspondance et le nom dérivé ; les groupes et la règle NACM ; l’identifiant RPC, la réponse, le datastore, le commit, la lecture après changement et l’observation opérationnelle séparée.

Ce niveau de détail permet de tester une rotation d’AC en mode fantôme. On peut savoir quels certificats d’autres usages passeraient la nouvelle ancre et quel nom chaque règle produirait, sans leur accorder de mutation en production. La PKI garde sa fonction ; elle cesse simplement de servir de réponse universelle à une question d’autorité locale.

Sources