Résumé

  • La protection de value par nacm:default-deny-all ne tranche pas l’accès à l’action distincte test. NACM exige la lecture des instances ancêtres identifiant l’action et le droit exec sur celle-ci. Les règles applicables et le contexte de session restent déterminants ; exec-default, dont la valeur standard est permit, intervient en dernier recours. RFC 9647, §2.3 ; RFC 8341, §§3.1.3, 3.4.5 et 5.1

  • Le test confronte les entrées de l’appelant à un calcul effectué avec la clé et l’algorithme configurés. Il renvoie une indication booléenne, sans restituer la clé ni le MAC calculé. Cette vérification peut servir au provisionnement ou à une rotation, à condition de disposer d’une référence pertinente. RFC 9647, §2.3

  • Un résultat positif ne prouve ni l’authentification de paquets en circulation, ni leur réception par un voisin, ni la disponibilité d’une route. Pendant une rotation, des échanges peuvent encore dépendre de l’ancienne clé. La décision de basculer exige donc d’autres preuves. RFC 8967, §§4–6

  • La responsabilité porte à la fois sur l’étendue du droit accordé et sur l’interprétation du résultat. Les propositions de gouvernance doivent rester distinctes des prescriptions techniques, notamment de la recommandation normative SHOULD concernant la comparaison en temps constant. RFC 9647, §4

Une permission dont le résultat tient dans un booléen

L’intérêt de l’action tient à une séparation précise : une personne peut vérifier une attente relative à une clé sans recevoir cette clé. Dans le modèle YANG de RFC 9647, l’objet associe notamment un nom, les indicateurs use-send et use-verify, un algorithme et une valeur destinée à rester illisible. L’action test est définie à l’intérieur de cet objet. RFC 9647, §2.3

L’appelant fournit test-string, une chaîne binaire, et mac, le MAC candidat auquel comparer le résultat. L’implémentation calcule localement avec la valeur et l’algorithme configurés, puis renvoie indication : vrai si les MAC correspondent, faux sinon. Le contrat de sortie ne lui donne ni les octets de la clé ni le MAC produit par l’équipement. RFC 9647, §2.3

La délégation est donc limitée, mais elle n’est pas vide. L’appelant choisit des données et demande au détenteur du secret de trancher une relation entre ces données, un résultat candidat et la clé. Il reçoit une réponse qu’il n’aurait pas nécessairement pu établir seul.

Cette capacité peut être utile sans devenir un droit général sur le secret. Un opérateur chargé d’une vérification n’a pas besoin de recevoir la valeur pour utiliser un couple de référence préparé par une fonction habilitée. Il peut se voir confier la tâche de confirmer une correspondance, tandis que la préparation de la référence et le provisionnement restent ailleurs.

La quantité d’information retournée ne suffit toutefois pas à définir la portée de l’autorisation. Celle-ci dépend aussi des objets accessibles, de la liberté de choisir les entrées et de la possibilité de renouveler les demandes. Le fait qu’une réponse soit booléenne ne dispense pas de décider qui peut la solliciter.

Cette observation ne démontre aucune récupération de clé, aucune falsification et aucun défaut dans une installation. Elle identifie une capacité de gestion que le modèle permet d’exercer et dont l’attribution doit être examinée comme telle.

L’autorisation se vérifie sur l’action

La feuille value porte l’annotation nacm:default-deny-all. L’action test est une autre partie du modèle. La protection attachée à cette feuille voisine ne constitue donc, à elle seule, ni une autorisation ni une interdiction d’exécuter l’action. RFC 9647, §2.3

La règle pertinente de NACM est explicite. Pour invoquer une action YANG, l’utilisateur doit pouvoir lire toutes les instances de nœuds ancêtres qui identifient cette action et disposer du droit d’exécution sur l’action elle-même. value n’appartient pas à cette chaîne d’ancêtres. La lecture nécessaire pour désigner l’instance ne se confond donc pas avec la lecture de ses octets secrets. RFC 8341, §3.1.3

L’évaluation doit ensuite porter sur les droits réellement appliqués à la session. Les groupes reconnus, la portée des règles et leur ordre comptent. La première règle correspondante décide de l’accès ; en l’absence de règle correspondante, le paramètre de repli exec-default intervient pour l’exécution. Sa valeur standard est permit. RFC 8341, §§3.4.5 et 5.1

Il serait donc incorrect de lire ce défaut comme une ouverture universelle. Une règle applicable peut refuser l’exécution, et les conditions de lecture des ancêtres doivent aussi être satisfaites. Il serait également incorrect de considérer que le secret est automatiquement à l’abri de toute invocation parce que sa valeur n’apparaît pas dans une réponse de lecture.

L’existence d’une règle restrictive dans un document ou dans une configuration ne suffit pas davantage. Il faut établir qu’elle correspond à la demande et qu’une autre règle ne détermine pas la décision auparavant. L’examen utile porte sur un compte, une session, une action et une instance identifiables.

Cette précision a une conséquence pratique pour les intitulés de rôles. Un compte décrit comme « lecture seule » peut avoir été conçu pour interdire les modifications sans exclure toutes les actions. L’étiquette administrative ne remplace pas l’évaluation de exec. De même, connaître le nom d’une clé ne confère aucun droit d’en déclencher le test.

L’administrateur doit s’assurer que NACM est activé et que les paramètres par défaut conviennent à la politique recherchée. RFC 8341 lui attribue cette responsabilité. Le choix des personnes ou fonctions qui devraient bénéficier du test reste, lui, une décision à prendre dans l’organisation. RFC 8341, §5.1

Désigner la clé ne dit pas qui en dispose

RFC 9046 explique la fonction du nom : identifier la clé alors que sa valeur ne peut pas être lue. Son §3.8 formule cette interdiction de lecture avec MUST NOT. Le nom fournit ainsi une référence utilisable pour la gestion, sans devenir une représentation des octets secrets. RFC 9046, §3.8

Un même libellé observé dans deux contextes ne prouve donc pas l’égalité des valeurs. Il ne désigne pas non plus, par lui-même, le propriétaire organisationnel du secret, les personnes habilitées à le provisionner ou celles autorisées à le tester. Ces rattachements demandent d’autres éléments.

Les indicateurs d’usage répondent à une autre question. use-send décrit l’emploi de la clé pour produire un MAC destiné aux paquets sortants ; use-verify décrit son emploi pour vérifier les paquets entrants. Le modèle ne les définit pas comme des permissions attribuées à un opérateur pour appeler test. RFC 9647, §2.3

Cette séparation permet de parler précisément des preuves :

Élément observé Information qu’il apporte Décision qu’il ne permet pas de prendre seul
Nom de la clé Référence de l’objet administratif visé Déclarer ses octets identiques à ceux d’une autre entrée ou attribuer son contrôle à une personne
use-send et use-verify Usages décrits pour l’envoi et la vérification des paquets Déterminer si un appelant possède le droit d’exécuter le test
Appel de test accepté Possibilité effective d’exercer l’action dans ce contexte Juger que cette possibilité correspond à un besoin organisationnel légitime
Résultat booléen Concordance ou discordance pour les entrées soumises Valider toute une configuration, une bascule ou la santé du réseau
Observation d’un paquet Contenu et événement visibles au point d’observation Affirmer sans preuve supplémentaire ce que le destinataire a vérifié ou accepté

Les trois premières distinctions découlent des objets de gestion et du contrôle d’accès. La dernière renvoie au traitement propre des paquets Babel. Les réunir évite qu’une référence administrative ou un résultat local soit promu en preuve d’une autre nature. RFC 9046, §3.8 ; RFC 8341, §3.1.3 ; RFC 8967, §§4–6

La référence donne sa valeur à la comparaison

Pour vérifier un provisionnement, un résultat attendu doit avoir une origine explicable. L’opérateur devrait savoir à quel objet, à quel algorithme et à quelle préparation de clé se rattache le couple chaîne-MAC qu’il utilise. La possibilité d’exécuter le test ne garantit aucune de ces correspondances.

Une organisation peut confier la production de cette référence à une fonction habilitée, puis en remettre les éléments nécessaires au vérificateur. Cette division du travail permet d’exercer un contrôle sans multiplier les copies de la clé. Elle constitue une utilisation possible du mécanisme, et non un partage des rôles imposé par la RFC.

La qualité du contrôle dépend de l’indépendance de la référence. Si une même erreur de préparation alimente le provisionnement et le résultat attendu, un accord peut reproduire cette erreur. Un dispositif défendable devrait donc pouvoir expliquer comment la référence se rattache à l’intention du changement, au lieu de considérer tout couple disponible comme une preuve suffisante.

Un résultat positif reste utile : pour les entrées choisies, l’implémentation indique que le calcul effectué avec l’objet visé correspond au candidat. Cette observation peut réduire une incertitude sur le provisionnement. Elle ne permet pas de conclure que toutes les associations d’interfaces, tous les voisins ou tous les usages prévus sont corrects.

Un résultat négatif doit être interprété avec la même discipline. Il peut être compatible avec une mauvaise cible, une référence périmée, une entrée mal préparée ou un couple clé-algorithme différent de celui attendu. La réponse ne désigne pas elle-même la cause à corriger.

Il faut enfin conserver la différence entre une discordance et l’absence de comparaison. Un refus d’accès, une erreur de traitement ou une réponse absente ne sont pas des résultats faux. Un outil qui fusionnerait ces états ferait disparaître la distinction entre un problème d’habilitation, un problème d’exécution et un désaccord cryptographique.

Une vérification ciblée peut associer un couple connu et un candidat volontairement incorrect. Elle peut aussi vérifier séparément qu’une identité habilitée obtient l’accès prévu et qu’une identité exclue reçoit un refus. Ces contrôles seraient des choix de validation : deux booléens ne suffisent pas à démontrer la politique d’accès, et quelques essais ne certifient pas toute l’implémentation.

Pendant une rotation, la continuité peut rester ambiguë

La rotation rend particulièrement visible l’utilité de cette délégation. Une équipe peut vouloir vérifier une nouvelle entrée sans demander à relire le secret qui vient d’être installé. Un accès limité à cette entrée peut l’aider à confirmer une attente avant de participer à une décision plus large.

RFC 8967 prévoit une transition avec chevauchement des anciennes et nouvelles clés. Les paquets peuvent alors porter des MAC calculés avec les deux clés, et une correspondance avec l’une peut satisfaire le contrôle MAC. Ce sont les MAC qui sont transmis, et non les valeurs secrètes des clés. RFC 8967, §§4.2 et 5

La conséquence analytique est importante : des échanges qui se poursuivent pendant cette phase peuvent encore dépendre de l’ancienne clé. Leur continuité ne démontre donc pas que la nouvelle suffit désormais. Le test local apporte une information différente, mais sa réussite ne supprime pas cette incertitude à elle seule.

L’authentification d’un paquet utilise les données structurées définies par RFC 8967, comprenant un pseudo-en-tête et le contenu Babel concerné. À réception, la concordance d’un MAC précède encore des contrôles portant sur le compteur, l’index et, selon le contexte, un challenge. Le traitement normal intervient ensuite. RFC 8967, §§4.1–4.3

Une chaîne binaire soumise à l’interface de gestion n’observe pas cette séquence dans le réseau. Même lorsqu’une comparaison porte sur des données tirées d’un paquet, elle ne prouve pas que ce paquet a effectivement été reçu puis accepté, à l’époque considérée, par le destinataire attendu.

La présence d’un MAC dans une capture ne donne pas davantage le résultat du contrôle effectué ailleurs. Le format du MAC TLV porte le MAC ; il ne transporte pas le nom administratif de l’objet de clé comme une attestation de sa configuration. RFC 8967, §6.1

Le responsable d’une bascule devrait donc annoncer ce qu’il entend conclure du test : confirmer une attente relative à une entrée déterminée, puis rechercher séparément les observations nécessaires à la décision de retirer l’ancienne clé. Le résultat local conserve ainsi toute son utilité, sans supporter une conclusion qui dépasse son champ.

L’autorisation du vérificateur devrait être alignée sur cette mission. Disposer du droit de tester une nouvelle clé ne signifie pas détenir le pouvoir de déclarer la rotation achevée. L’autorité de produire une preuve et celle de décider à partir de cette preuve peuvent être confiées à des fonctions différentes.

Le temps de réponse reste dans le périmètre d’examen

RFC 9647 souligne la nécessité de contrôler l’accès aux actions sensibles. Elle signale également que des informations pourraient être révélées indirectement, notamment par le temps de réponse, et recommande que les implémentations comparent le MAC fourni et le MAC calculé localement en temps constant. La force normative employée est SHOULD. RFC 9647, §4

Le contrat booléen décrit ce qui doit être retourné comme résultat. Il ne suffit pas à établir que toutes les autres caractéristiques observables de l’exécution sont dépourvues d’information. L’avertissement de la RFC justifie donc un examen de l’implémentation, sans constituer la constatation d’une fuite.

La recommandation concerne la comparaison. Elle ne promet pas que la durée totale de toutes les requêtes sera identique, indépendamment des entrées et du contexte de traitement. Une variation de latence isolée ne démontre pas un canal exploitable ; une apparente stabilité ne prouve pas davantage l’absence de problème.

Une politique d’assurance pourrait demander au fournisseur ou au mainteneur comment cette comparaison est réalisée et vérifiée, ainsi que les raisons d’un éventuel écart à la recommandation. Cette demande de preuves est une proposition de gouvernance. Elle doit préserver la distinction entre SHOULD et MUST, sans transformer la première en simple préférence facultative ni en obligation absolue.

Des limites de fréquence ou des restrictions supplémentaires sur les entrées peuvent aussi être envisagées selon les besoins. Elles ne doivent pas être présentées comme des paramètres universels imposés au test par ces textes. Leur justification porterait sur la capacité que l’organisation accepte de déléguer et sur les conditions dans lesquelles elle souhaite la rendre utilisable.

Une responsabilité à répartir, une utilisation à attribuer

Les RFC établissent des objets, des contrôles et des limites techniques. Elles ne nomment pas la personne qui, dans une organisation, doit approuver le besoin d’un opérateur. Ce choix ne disparaît pas parce que le serveur sait appliquer une règle.

Une répartition défendable distinguerait celui qui justifie l’usage du secret, celui qui traduit cette justification en habilitation, celui qui réalise le contrôle et celui qui accepte les conclusions du résultat. Ces fonctions peuvent se recouper dans une petite équipe. L’essentiel est de ne pas laisser leur responsabilité se dissoudre dans un intitulé générique d’administrateur.

Un accès trop large facilite les vérifications immédiates, mais étend le nombre d’identités capables de soumettre leurs propres questions au secret. Un accès trop étroit peut retarder une vérification utile et concentrer les interventions sur quelques comptes plus privilégiés. Aucun de ces coûts ne se résout en regardant seulement si la feuille value reste illisible.

La médiation par une automatisation ajoute une question d’attribution. Si l’équipement reçoit l’appel sous un compte de service, l’identité technique observée ne désigne pas automatiquement la personne ou le processus qui l’a déclenché. Il faut pouvoir relier la demande initiale à l’exécution par une chaîne de traces fiable.

Une mention déclarative du nom d’un opérateur ne suffit pas à établir cette relation. De même, le fait qu’un compte de service soit autorisé ne démontre pas que tous les utilisateurs d’un outil devraient pouvoir mobiliser ses droits. L’examen doit suivre la demande jusqu’à l’identité sous laquelle le secret est effectivement sollicité.

Une trace utile devrait permettre de retrouver la cible, le moment, l’identité effective, la référence employée et le résultat, ainsi que le contexte nécessaire pour expliquer l’autorisation. Cette explication peut renvoyer à une règle ou à un mécanisme de repli ; elle ne doit pas supposer qu’une permission explicite a nécessairement décidé chaque appel.

Cette traçabilité n’exige pas de journaliser la clé. Elle peut reposer sur des références contrôlées aux entrées et à l’état concerné, avec un accès limité aux éléments nécessaires. Ce sont des choix de conception d’audit, dont la valeur tient à ce qu’ils permettent de démontrer.

La question centrale peut alors recevoir une réponse complète. Peut appeler le test l’identité dont les droits effectifs satisfont les conditions d’accès à l’action sur l’instance visée. Devrait recevoir cette capacité l’identité dont le besoin, le périmètre et la responsabilité ont été décidés. Un résultat vrai prouve une correspondance dans ce cadre ; il ne peut approuver rétrospectivement l’habilitation de celui qui l’a obtenu.

Sources