Summary

  • RFC 3594 lets a provider use DHCP to order a CableLabs client to invalidate selected security tickets held in nonvolatile storage. The receipt belongs to the device cache; it is not server-side revocation, removal of a live security association, or successful reacquisition.
  • Fleet-wide invalidation changes the arrival pattern at shared authentication systems. A correct security action can still synchronize PKINIT, ticket and application-server work into an avoidable capacity event.

At 02:00, an operator sends a credential-reset instruction to a maintenance cohort. At 02:01, the console reports that the reset is complete. At 02:02, the first devices ask the security infrastructure for replacement material. At 02:03, queues rise.

The console did not necessarily lie. It answered the wrong question. It recorded that a local copy was invalidated and displayed that fact as though the whole recovery chain had finished.

RFC 3594 is a short Standards Track document from September 2003. It adds Security Ticket Control, sub-option 9, to the DHCP CableLabs Client Configuration option. The wire object is only four bytes after framing: a code, a length of two and a 16-bit Ticket Control Mask. Yet that compact command exposes a durable leadership problem. Security state is distributed, and deleting one representation does not settle all the others.

The mask names local storage, not the whole trust system

PacketCable devices could keep valid Kerberos tickets in nonvolatile memory. A rebooted device could reuse them rather than repeat expensive acquisition, including public-key work on the PKINIT path. The later frozen CableLabs security specification makes the optimization explicit: an MTA stores its provisioning-server service ticket and enough Call Management Server tickets for its endpoints.

RFC 3594 gives the provider a way to override that reuse. Bit 0 addresses the provisioning-server ticket. Bit 1 addresses the group of all CMS tickets used by the device. Bits 2 through 15 were reserved and had to be sent as zero. A one means immediate invalidation of the corresponding locally persisted ticket or group; a zero leaves normal invalidation rules in force.

The nouns constrain the claim. “Locally” identifies the authority boundary. “Persisted” identifies the representation. “Ticket” identifies the credential object. The sub-option does not contain a KDC acknowledgement, an application-server response, a Security Association identifier, or a call result.

That is why “credentials revoked” is too broad. The command can remove a device's reusable copy without proving that a server rejected the ticket, that an in-memory copy disappeared, or that already established security parameters were torn down. The later CableLabs text says a ticket-renewal exchange can finish without affecting existing security parameters. Ticket state and live association state are deliberately separate.

Ignore behavior is part of the protocol outcome

RFC 3594 requires a device that does not store tickets locally to ignore the sub-option. It also requires unknown bit values to be ignored. Those rules prevent a sender from treating every delivered mask as an effective mutation.

Consider two devices that receive the same bytes. One has the selected CMS tickets in nonvolatile storage and invalidates them. The other has no persisted tickets and correctly does nothing. Both can be conformant. A delivery counter cannot distinguish their postconditions.

The evidence chain therefore needs a parser receipt and a storage receipt. The parser receipt binds the option code, declared length, exact two mask bytes, supported semantics and ignore decision to one device and one boot epoch. The storage receipt identifies what existed beforehand, which class was selected, when invalidation occurred and whether the deletion survived a reboot.

A zero bit is not an affirmative statement that the relevant ticket remains usable. It merely leaves the ordinary rules in charge. Expiry, a service-key change, local replacement or another failure can still make the ticket unusable. In the other direction, a one bit is not proof of remote revocation. The mask changes a local decision surface; it does not broadcast a universal truth.

The reset command also schedules demand

Persistence saves work. Removing persistence restores that work. The cost becomes operational when many devices cross the boundary together.

RFC 3594's security section describes exactly this risk. If many MTAs are reset or power-cycled, receive a malicious instruction to invalidate all security tickets, and then authenticate simultaneously, the security infrastructure can face a denial-of-service condition. The harm is not a forged cryptographic result. It is correlated legitimate demand triggered through a configuration path.

The same mechanism can exist without a malicious actor. A well-intended fleet reset with no cohorting or jitter can reproduce the arrival pattern. Each device may behave correctly. The KDC may behave correctly. The application servers may behave correctly. The system can still fail because independence at the endpoint was replaced by synchrony at the control plane.

This changes how a security maintenance window should be approved. The plan needs the intended cohort size, expected ticket classes, KDC and application-server headroom, arrival-rate budget, retry/backoff distribution, a stop threshold and an observation window long enough to see replacement work. “The option was sent” is the beginning of the load model, not its end.

The later CableLabs specification reinforces the point from another direction. During routine service-key rollover, an application server retains older valid keys for at least the relevant ticket lifetime. The stated reason is to prevent many MTAs from suddenly flooding a KDC with PKINIT requests. Compatibility and capacity are coupled; a sharp security boundary can become a queue.

Network filtering is a control, not an observation receipt

The RFC judged its malicious-server scenario unlikely in the described cable architecture. A correctly configured CMTS forwards client DHCP requests only to configured server addresses and permits downstream DHCP traffic only from specified server addresses. It also notes the limitation: downstream filtering does not stop a spoofed DHCP server behind the CMTS, where the provider-controlled network is assumed to be trustworthy.

That assessment should not be copied into a present risk register as a measured probability. It states an architectural dependency and a trust assumption. Evidence still has to identify the authoritative DHCP server, relay and CMTS path, source filtering policy, configuration version and device-side transaction match.

Authentication for DHCP messages, described separately in RFC 3118, is another control surface. Its existence does not prove deployment or acceptance in a particular PacketCable path. The IANA registry's entry for sub-option 9 proves coordinated allocation. It does not prove that a device supports the option, that a server sends it, or that filtering and authentication are effective.

The leadership question is not whether the design has controls. It is which concrete receipt shows that each control operated during this change.

Four states must remain separate

A useful operations model exposes at least four columns.

First, ticket invalidated: the selected object is absent or unusable in the device's persistent store. Second, replacement obtained: the device completed the necessary AS or TGS path and holds a new ticket with a known lifetime. Third, association rebuilt: the AP exchange completed and the relevant security parameters or IPsec SAs were installed at both ends. Fourth, service verified: the provisioning or call-management transaction completed and, if claimed, the user-visible result occurred.

Each column has a different owner and failure mode. Storage can succeed while the KDC is unreachable. Ticket acquisition can succeed while the application server rejects the AP request. An association can exist while application state was lost. A successful server transaction can still precede a failed call or subscriber outcome.

Combining those columns into reset_complete=true destroys the distinction that an incident review needs most. It also creates perverse rollback logic. Restoring an old dashboard flag cannot reconstruct a deleted ticket, reverse a burst of retries, or show which CMS ticket group was affected.

Evidence boundary

This Article identifies no cable operator, MTA model, CMTS, DHCP implementation, KDC, CMS, subscriber, call, outage or deployment rate. It describes RFC 3594's bounded command and later primary context. Standards Track status and IANA registration do not establish implementation.

RFC 3495 defines the larger CableLabs Client Configuration option. RFC 2131 supplies DHCP context, RFC 3118 the separate authentication mechanism, and RFC 1510 the Kerberos version cited by RFC 3594; RFC 4120 is later Kerberos lineage. RFC 3634 adds another CableLabs client sub-option but does not expand the ticket-control claim. RFC 2434 and RFC 8126 explain historical and current registry policy. The frozen 2005 CableLabs specification is later primary implementation context, not RFC 3594 normative text.

Heng Lu's Running-Code Primacy and Minimum Initial Specification essays are disclosed editorial lenses. They support asking for device-side and service-side receipts rather than treating a configuration declaration as an outcome, and keeping the shared command narrower than local rollout policy. They do not prove the RFC author's intent or any deployment fact.

The conclusion is exact: the mask can clear a local cache entry. Preserve that result. Then watch the independent work it releases into authentication, association and service systems.

Sources