Summary

  • RFC 9684 defines YANG RPCs for a Verifier to request nonce-bound TPM 1.2 or TPM 2.0 quotes and retrieve measurement logs from a network device.
  • A valid response protects selected PCR Evidence at a particular challenge, but it does not prove that the right TPM, PCRs, files, Reference Values or appraisal policy were selected.
  • The operational chain still needs separate receipts for attestation-key binding, log reconstruction, Evidence appraisal, the Attestation Result, Relying Party authorization, enforcement and observed network outcome.

The nonce was new. The TPM signature verified. The PCR values matched the event log that arrived beside them. The device had answered exactly the challenge it was sent. The security team still could not say whether the router should remain in service.

The missing fact was not cryptographic validity. It was the scope and authority of the conclusion. The request had selected one TPM and one PCR bank. A line-card controller used another measurement root. The Reference Values belonged to the previous approved image. The signed response was real, fresh and too narrow for the decision waiting above it.

RFC 9684 standardizes an important part of this exchange. Its CHARRA YANG model lets a client request TPM quotes, inspect attestation support structures and retrieve BIOS, IMA or network-equipment boot logs through NETCONF or RESTCONF. It gives interoperable shape to Evidence retrieval. It does not make the Evidence appraise itself.

A fresh challenge proves a bounded time claim

The ietf-tpm-remote-attestation module requires the YANG client to supply a fresh nonce with suitable entropy. The Attester incorporates that challenge into its response, allowing the receiver to reject an old quote replayed as if it described the current interaction.

That is a meaningful receipt. It binds the response to this challenge rather than a previous one. It does not freeze the device after the quote. It does not reveal a measurement the request never selected. It does not prove that every component capable of changing forwarding behavior is represented by the TPM that answered.

RFC 9684 states this boundary directly for composite devices: the method for communicating the relationship between each TPM and the particular measured component is outside its scope. On hardware with several TPMs, the mtpm feature matters. If a requester omits certificate names, all compatible TPMs can respond. If it supplies one, the resulting precision is only useful when the certificate-to-TPM-to-component mapping is itself trustworthy.

The durable challenge record therefore needs more than a nonce and response timestamp. It needs the device identity, RPC, selected TPM version, certificate name, PCR indices, hash bank, requested log type and the configuration version that made those selections. “Quote valid” without that envelope preserves the mathematics while losing the question that was answered.

A signature does not validate its own signer

For TPM 2.0, the response can include TPMS_QUOTE_INFO, a quote signature, uptime, certificate name and unsigned PCR values. Those fields are not interchangeable. The signature protects the attested structure. The PCR values make inspection and reconstruction possible. The certificate name selects the credential expected to connect the signing key to a legitimate attestation role.

RFC 9684 requires the receiver to verify that a TPM 1.2 certificate is for an active Attestation Identity Key, or that a TPM 2.0 certificate corresponds to an active Attestation Key whose private-key control has been confirmed for an entity legitimately able to attest for the targeted TPM. A clean signature from an unexpected key is not a successful device appraisal.

The model also exposes writable support structures. A certificate can be provisioned that does not correspond to the expected AIK or AK. A key type can be represented incorrectly. An algorithm list can claim support the physical TPM does not provide. PCRs that system software never extends can be configured for extraction. Each failure can leave the transport healthy and the RPC syntactically successful.

This is why secure management access and attestation truth must remain separate. RFC 6241 and RFC 8040 provide the NETCONF and RESTCONF surfaces. Their protected transports help establish who exchanged the management message and prevent modification in transit. They do not decide whether the named key belongs to the intended TPM or whether that TPM measures the component leadership cares about.

PCR agreement is a consistency proof, not a completeness spell

A TPM PCR is a rolling hash. It can commit to an ordered sequence of measurement extensions without carrying the explanatory detail of every extension. The event log supplies that detail. A Verifier can replay the log, compute the expected PCR value and compare it with the signed Evidence. It can then compare measured files with approved Reference Values and locate mismatches.

That chain is powerful precisely because each dependency is visible. The quote can match the PCR while the event log is absent. The log can replay correctly while its measurement policy omitted the file that matters. The file can be measured while the Reference Value is stale. The Reference Value can be current while the Relying Party applies an obsolete authorization rule.

Appendix A of RFC 9684 makes the scope problem concrete. Linux IMA templates determine what fields a measurement record carries. IMA policy determines which files are measured. If no policy is defined, no measurements are taken and IMA is effectively disabled. A perfectly reconstructed empty or narrow measurement surface is not evidence that everything outside it is good.

The same caution applies to the available log families. BIOS/UEFI, IMA and network-equipment boot logs speak about different stages and components. Parallel execution complicates the order a reviewer expects. Updates and patches legitimately change measurements, which means the Reference Integrity Manifest must evolve. A mismatch may indicate tampering, but it can also indicate a deployment that moved before its approved baseline. The receipt establishes difference; attribution needs more facts.

Evidence, appraisal and authorization have different owners

RFC 9334 gives the wider RATS architecture its essential separation. The Attester produces Evidence. A Verifier appraises that Evidence against Endorsements, Reference Values and policy. It produces an Attestation Result. A Relying Party then uses that result under its own policy for a specific decision.

RFC 9684 mainly improves the first handoff. It lets network management systems retrieve Evidence in a common model. RFC 9683 supplies the network-device remote-integrity context, including manufacturers or other accepted providers of Endorsements and Reference Values. Neither document turns the Verifier into a universal business authority.

A device can therefore produce authentic Evidence and receive an adverse appraisal because the approved baseline differs. It can receive a favorable Attestation Result and still be denied network admission because the transaction demands a newer policy. It can be authorized to remain connected while a separate maintenance process isolates one function. The subjects change at every step.

The final operational receipt belongs to the enforcement point. If a controller receives “deny,” did it change admission state? Did the router withdraw a session? Did traffic move? Did a redundant path preserve service? None of those facts is inside a TPM quote. Treating them as implied makes a cryptographic component responsible for actions it cannot observe.

The Evidence interface is itself a protected asset

Attestation data can reveal software and configuration versions. Event logs contain digests that can help an observer identify a vulnerable build. Large log requests can consume enough device resources to create denial-of-service pressure. RFC 9684 therefore calls for RFC 8341 NACM protection with a deny-all default for these RPCs, admitting only authorized Verifiers.

That authorization is not clerical. A Verifier able to query every PCR and pull large logs gains a detailed view of fleet composition and a way to impose work on critical devices. The minimum common interface should expose enough for interoperable Evidence retrieval while local policy decides who may ask, how often, for which components and at what log volume.

This is the governance pattern described in Minimum initial specification: standardize the narrow exchange, keep future operational choices visible and local. Reality layers prevents the label “attested” from swallowing nonce, signature, measurement, baseline and decision. Running-code primacy requires the last step: inspect the system that actually enforced the result.

RFC 9684 makes a TPM answer portable across management systems. Its success should be recorded exactly at that boundary. A fresh quote is Evidence. It becomes a verdict only after an accountable Verifier uses the right scope and baseline; it becomes an operational fact only after an authorized system acts.

Sources