Summary

  • Withholding a key’s value and authorising its test are separate decisions. The caller needs read access to the action’s identifying ancestors and effective execution permission. NACM’s standard execution fallback is permit, but applicable rules and session context still determine access. This establishes neither universal availability nor a deployment flaw. RFC 9647, §2.3, RFC 8341, §§3.1.3, 3.4.5 and 5.1

  • Delegated testing can let an operator check provisioning without receiving the secret. The result remains a local comparison whose value depends on a trustworthy expectation and an attributable request. During rotation, continuing traffic may still rely on the old key, so a successful test cannot by itself justify removing that dependency. RFC 9046, §3.8, RFC 8967, §§4–5

The operator has a question for a secret

Consider a hypothetical operator preparing to check a configured Babel MAC key. The management system exposes enough information to identify the key object, but the operator cannot read its value. If effectively authorised to invoke the object’s test action, the operator can submit two binary inputs: a test string and a candidate MAC. The device calculates locally and returns only whether its result matches the candidate.

The operator has asked the device to exercise a secret that remains unavailable for inspection. There is no need to assume a fault in that arrangement. It could express precisely the intended division between the person responsible for supplying secret material and the person responsible for checking a configuration step.

What needs explanation is the authority behind the request. Being responsible for a maintenance task does not itself establish execution permission. Equally, receiving a successful response does not establish that the organisation intended the caller to have that permission.

These are two different judgments: whether the management service admits the request, and whether the admitted request fits the operator’s responsibility. A third follows when someone uses the answer to approve a change.

The governance question runs through all three. Who may cause the computation, who is accountable for that delegation, and which decision can the narrow result reasonably support?

A computation with a deliberately limited output

RFC 9647 places the test within an individual entry of mac-key-set/keys. The entry models a key name, use-send, use-verify, algorithm and value. The value leaf carries nacm:default-deny-all. The action takes caller-supplied test-string and mac inputs, both binary, and uses the configured key and algorithm to calculate a MAC over the supplied string. Its Boolean indication reports a match or mismatch. Neither key bytes nor the locally calculated MAC are returned. RFC 9647, §2.3

That output restriction matters. The caller must bring a candidate to the comparison. The interface does not provide a newly calculated authentication code for the caller to take away. Describing it as unrestricted MAC generation would exaggerate the specified capability.

Yet the response still conveys something about the relationship between the submitted data and the installed secret. Permission to obtain that answer is therefore meaningful, even when the output is small.

RFC 9046 supplies the information-model foundation. Its §3.8 requires the key value to be unreadable, explains the identifying role of the name and describes the optional expected-result test. RFC 9647 turns those management concepts into a YANG representation. The information model’s secrecy requirement, the YANG leaf protection and the access policy applied to the action are related claims, not interchangeable ones. RFC 9046, §3.8

A match also says nothing by itself about how the caller obtained the candidate. An operator could receive an approved test pair without possessing the key. Consequently, successful use of the interface is not proof that the caller knows the secret. That distinction is central to its legitimate operational value.

Authorisation is resolved outside the secret leaf

The protected value leaf is a sibling of the action. Its access restriction does not automatically extend sideways to settle execution of test.

Under RFC 8341 §3.1.3, an action invocation requires read access to all ancestor data-node instances identifying the action, together with exec access to the action itself. The secret-value sibling is outside that ancestor chain. Reading the identifying hierarchy does not mean reading every descendant within it. RFC 8341, §3.1.3, RFC 9647, §2.3

For ordinary sessions with NACM enabled, applicable rules are evaluated in order. A matching rule can permit or deny the request; only when no applicable execution rule matches does exec-default decide. Its standard default is permit. An explicit permit therefore settles execution without reaching the fallback, just as an effective denial does. RFC 8341, §§3.4.5 and 5.1

The practical conclusion is conditional. A caller with the required ancestor access may be admitted through the execution fallback if no matching rule decides otherwise. A different configured default or an effective restrictive rule can produce a different outcome. Permission to execute cannot compensate for missing ancestor access.

The assessment must also follow the session identity and relevant group memberships. NACM can incorporate local and enabled transport-provided groups. Nested actions are matched through data-node paths, and broader rules can cover their descendants. RFC 8341, §§3.4.5–3.5.2

This makes a role label an inadequate substitute for an access assessment. A role called “observer” might prohibit configuration changes while still allowing some actions. A role called “administrator” might be constrained for a particular target. The relevant evidence is the decision for that session, operation and key instance.

Nor does finding a restrictive rule somewhere in a configuration establish that it controls the request. Its applicability and position matter. A review needs to explain the rule that actually decides, or the fallback reached after evaluation.

The standards establish that decision procedure. They do not establish which accounts a particular deployment admits, or whether an admitted account exceeds its intended responsibilities.

The key’s name does not appoint its custodian

A management identifier gives people and software a way to refer to an object whose secret value is unavailable. It does not assign organisational ownership.

A meaningful reference therefore needs its surrounding context: the device, Babel instance, key set and individual key entry. A name that is convenient for a local operator may be insufficient in a central change record containing results from many devices.

That distinction also separates inventory responsibility from permission to use the secret. Someone may maintain names and lifecycle records without needing to submit comparisons. Another person may be authorised to run a specific diagnostic without controlling provisioning. The organisation has to make those relationships explicit; a label in the model cannot make the decision for it.

The packet-use flags have their own defined purpose. use-send addresses computation of MACs included in outgoing Babel packets, while use-verify addresses use of the key for incoming MAC comparisons. Neither is specified as an authorisation switch for the management action. The test is not stated to require either flag to be true. RFC 9647, §2.3

This gives a configuration check a potentially useful place before packet use begins. It also means that ending packet use does not, through those flags alone, withdraw test access.

An organisation may reasonably retain an object temporarily for diagnosis after changing its packet role. The important point is to distinguish that decision from retiring all authority over the object. “No longer used for sending” is a narrower statement than “no operator may ask the device to test it.”

Delegation can reduce the number of people handling the key

One possible provisioning process would install the secret through an authorised mechanism and provide a maintenance operator with a test string, an expected MAC and an unambiguous target reference. The operator could check the installed object without receiving the underlying key.

The test would then support a defined acceptance question: does this object, using its configured algorithm, produce the expected answer for these bytes? This is a practical application of the expected-result operation described by the Babel models, rather than a workflow mandated by them. RFC 9046, §3.8

The independence of the expectation determines how much confidence the check adds. If the process installs unintended material and calculates its expected result from the same unintended material, the comparison can succeed. It would demonstrate consistency between two outputs of that process, while leaving the original selection error unresolved.

That does not make the test worthless. It defines the question the test answered. Evidence that provisioning transferred a chosen value correctly can be useful even when a separate approval establishes whether that value was the intended one.

The operator also needs control over the meaning of the inputs. A mismatch could arise from selecting the wrong object, using different binary data, associating the expectation with another algorithm or providing an incorrect candidate. Replacing secret material before resolving those possibilities could introduce a new change without diagnosing the first discrepancy.

Permission failure must remain separate from comparison failure. A request that the service refuses has not produced the action’s Boolean false. A management error likewise cannot be silently interpreted as evidence that the candidate failed to match.

This distinction has an immediate operational consequence. If an automation wrapper converts every unsuccessful request into a “key invalid” status, a change in access rights could start a provisioning investigation. Engineers could then be pressured to alter a correct configuration because the reporting system lost the distinction between authority and computation.

A well-defined delegation would preserve that distinction in both the interface presented to the operator and the record passed to the next decision-maker.

The costs of broad and narrow access fall on different teams

Broad test access reduces the coordination needed to investigate a configuration question. An engineer can obtain an answer without first locating a specialist or arranging another account. That convenience may be valuable during a tightly scheduled rotation.

Its cost is a larger set of people or processes able to select installed secrets for comparison. The relevant scope includes which key objects they can address and how much control they have over the submitted inputs. The fact that they cannot read the values does not make those choices irrelevant.

Narrower access reduces that discretion but can transfer work to a smaller group. If the authorised group is unavailable, a simple diagnostic becomes a scheduling dependency. Delays can then encourage requests for broader credentials or prolong uncertainty about whether a planned change is ready.

These are possible incentives, not reported conduct. The sources do not establish that any operator has shared credentials, exported a key or deferred a rotation because of this action’s policy.

The decision should nevertheless account for those pressures. A design that sharply limits direct test access while offering a reliable route for authorised maintenance may achieve a better separation of responsibilities than either indiscriminate access or an impractical restriction.

The useful comparison is between complete working arrangements. Counting how many accounts have an execution grant tells only part of the story if one of those accounts serves a large population through an intermediary.

Constant-time comparison and access control address different responsibilities

RFC 9647’s security section calls for controlling access to sensitive actions and warns that response timing can disclose information indirectly. It states that implementations SHOULD compare the supplied and locally generated MACs in constant time. This is a recommendation about the comparison, not a promise that every complete management request has identical elapsed time. RFC 9647, §4

The implementation question is whether the comparison behaves appropriately. The governance question is whether the caller should be allowed to request it. Evidence supporting one does not resolve the other.

A sound comparison routine would not explain why a diagnostic account needed authority over every retained key. A tightly scoped role would not eliminate the need for appropriate comparison behaviour.

The warning also has an evidential boundary. It does not demonstrate leakage in an implementation, establish that anyone can recover a MAC through this interface or describe a measured attack. Such conclusions would require evidence beyond the four standards.

An organisation could consider limits on invocation volume or additional controls around automated use. Those would be deployment choices that need to fit the intended workload. Restrictions that obstruct legitimate checks during a coordinated change could create a different operational problem.

Rotation tests the meaning of a successful answer

Rotation brings the permission question into contact with a consequential decision: when can the old key be removed?

RFC 8967 describes an overlap in which old and new keys coexist. Packets carry MACs computed with the applicable keys, and a matching MAC under an accepted key can satisfy the MAC check. The transmitted values are MACs, not the secret key bytes. RFC 8967, §§4–5

A local test of the new object can therefore succeed while continued packet acceptance still depends on the old material. The two observations concern different parts of the change. Their coexistence does not establish that removing the old key will preserve operation.

The technical distinction is concrete. RFC 8967 computes packet MACs over an address-and-port pseudo-header together with the Babel header and body, excluding the trailer. Reception also involves packet-counter, index and challenge-related checks. The management test performs its comparison over the caller’s supplied binary string. RFC 8967, §§4.1–4.3

Even a test using bytes corresponding to a real packet computation would not establish that a peer received or accepted that packet. Nor would it establish subsequent route state or network health.

The management key name does not close that gap. The MAC TLV carries no corresponding key-name field, so an observer cannot simply read a packet as a receipt naming the management object responsible. RFC 8967, §6.1

The person approving cutover consequently needs evidence directed at the remaining dependency. Depending on the available instrumentation and maintenance design, that could include receiver-side observations associated with the replacement configuration or a controlled transition that examines whether the old material remains necessary. The standards do not prescribe one universal proof package.

This is where the authority to test must remain distinct from the authority to approve removal. An operator can be fully entitled to run the local check and correctly report a match without having obtained the evidence needed for the broader decision.

A change record that preserves that distinction protects both the network decision and the operator’s accountability. It prevents a narrow, accurately reported observation from acquiring a stronger meaning as it moves through approval systems.

The request needs an attributable history

To assess effective rights, an organisation needs more than an inventory of configured grants. It needs to connect the relevant identity and session context to the target and the applicable decision. For the result to remain useful, that connection must also survive in the operational record.

A suitable record could identify the initiating principal, device and key-object context, approved test reference, policy context, time and outcome. It could distinguish a denied request from a completed mismatch or match. These are proposed audit properties, not a record format mandated by the test action.

Service accounts make the distinction especially important. At the device, the apparent caller may be an automation identity. The human capability behind it depends on what the automation service allows.

One service design might run only approved test pairs against objects assigned to a maintenance task. Another might forward arbitrary object selections, test strings and candidate MACs. Both could use the same device credentials while allocating substantially different discretion to their users.

A device log naming the service account would not explain that difference. Assessing the delegation would require examining the intermediary’s controls and preserving the association between its device-facing call and the person or authorised job that initiated it.

The expected-result reference also needs enough lifecycle context to remain intelligible. If an object is removed and a later object receives the same name, a historical match recorded only against that name may become ambiguous. Keeping the relevant configuration or object-generation relationship avoids treating a familiar label as permanent evidence of identical material.

Retaining every raw input is not automatically necessary. A controlled reference can preserve the meaning of an approved test without distributing its contents through every operational log. The choice should follow what reviewers will need to reconstruct, with appropriate protection for the resulting records.

An audit trail should explain the original decision, not merely celebrate a successful computation. It should be possible to determine why this caller could exercise this object and why the resulting observation was sufficient for the next authorised step.

The standard leaves a decision for the operator of the system

The four RFCs establish a useful separation. A key can remain unreadable while an authorised management operation uses it to check a supplied expectation. That separation can support disciplined maintenance and reduce the need to distribute secret material.

It also leaves a specific responsibility with whoever operates the management environment. The right to invoke the test must be assessed on its own terms, including the people behind service accounts and the scope of objects and inputs they can select.

No evidence here identifies a vulnerable deployment or a universal permission. The defensible public conclusion is narrower: protecting the value does not settle execution, and successful execution does not settle the operational change that follows.

A mature decision process can explain both permissions. It can identify who may request the comparison and who may rely on its result for a stated purpose. The secrecy of the key makes that explanation more necessary, because inspection of the value is deliberately unavailable as a substitute.

Sources