Summary

  • RFC 5295 derives cryptographically separate usage and domain root keys from an EMSK, but the KDF is only the first boundary; identifiers, callers, caches, lifetime and distribution must preserve it.
  • Evidence must link each derived value to its usage label, optional context, domain, parent session, authorized recipient and observed child protocol instead of treating “different key” as an end-to-end verdict.

The derivation passed; the migration failed

A roaming-access platform moved a subscriber into a new key-management domain. Both sides calculated the intended Domain-Specific Root Key. Yet one service selected an earlier root from cache because the receiving component had the bytes but not an unambiguous name and expiry. The cryptographic test passed. The system used the wrong generation.

RFC 5295 is often remembered as a formula. It is better read as a separation contract. The EMSK is retained inside the EAP peer and server and is used to derive roots for specific usages. A Usage-Specific Root Key is calculated from the EMSK, a key label, a null delimiter, optional data and an output length. The delimiter prevents prefix collisions between labels. A deterministic KDF means identical inputs produce identical output.

None of that says a cache, API or recipient knows what the output means.

A namespace is part of the security boundary

Each usage needs a definition with a distinct, coordinated label. Labels are printable, case-sensitive identifiers, not informal comments. Optional data can bind additional context. A derived USRK name may use the EAP Session-ID with the same label and optional data, giving parties a reference that does not disclose the root itself.

This coordination is not clerical decoration. If two teams allocate labels differently, truncate context, canonicalize it differently or index a cache only by user identity, cryptographically separate outputs can be placed into the same operational slot. The KDF did its job; the namespace did not.

The evidence receipt should therefore record the registered Usage ID, exact label bytes, delimiter, optional-data hash, requested length, KDF version, EAP Session-ID, EMSK name and resulting key name. “Derived successfully” omits the coordinates that make later replay possible.

A domain is a capability boundary

RFC 5295 defines a DSRK for a particular key-management domain. Its domain label enters the derivation, and Domain-Specific Usage-Specific Root Keys sit beneath it. A domain is the set of systems allowed to derive, use or distribute material within that scope. Child scope must be no broader than parent scope.

This creates a practical rule: a domain that is entitled to one function should receive the corresponding DSUSRK, not a DSRK from which it could derive every function in the branch. Sending a broader root because it is operationally convenient converts a cryptographic hierarchy into an administrative promise.

Domain names also require a shared canonical interpretation. Deriving different keys from differently rendered names is a visible failure. More dangerous is routing the correct DSRK to a component whose authority was never limited to that domain.

Rotation is not deletion

A root key must not outlive its EMSK. Once the EMSK expires, roots derived from it leave use. When a later EAP exchange creates a new EMSK, a usage should begin using the new roots as soon as possible. Whether child keys must be replaced depends on the usage definition.

That last sentence prevents a tempting fiction. New derivation is not evidence that every old child, cache replica or remote copy disappeared. Rotation needs an inventory and an observable retirement event. A system that records only the new key can be green while an old branch continues to authorize work.

Lifetimes also cross components. If a distributed root arrives without its expiry, the receiver may invent one. If it receives an expiry but not the parent generation, it may bind the constraint to the wrong session. Time is part of key context, not a dashboard annotation.

The interface should expose roots, not the EMSK

The RFC recommends keeping the EMSK close to its derivation point and exposing an interface for obtaining roots. Callers may be restricted to particular keys. Lower layers and external entities must not assume access to the EMSK.

An interface can return the right value to the wrong caller. That is not a failure of the PRF. It is an authorization and provenance failure at the API boundary. Logs should name the caller, requested usage and domain, policy decision, returned key name and parent generation without logging the secret.

The same restraint applies upward. Higher-layer applications should not rely solely on keys derived from network-access authentication. A performance shortcut can create a hidden dependency on access technology and leave the application unable to operate or rotate safely on paths without EAP.

Distribution must carry meaning with secrecy

Some roots have to move. RFC 5295 requires confidentiality and integrity in transit, authenticated and authorized parties, and transmission of context identifying the key and constraining its use, including lifetime. It deliberately does not specify a transport protocol.

Encrypting a payload proves only that outsiders could not read it. If the envelope omits key name, domain, usage, parent session or expiry, the receiver can protect the wrong meaning perfectly. Distribution evidence needs sender and recipient identities, authorization results, protected-channel binding, payload hash, key name and constraints, plus acknowledgement that the recipient installed the intended generation.

A stronger child cannot emerge from a weaker parent

Derived-key strength never exceeds the EMSK or the EAP method’s internal master key. More labels do not create more entropy. When a root produces many children, the child derivation may need fresh randomness supplied by the participating parties.

This is another reason not to equate architectural complexity with security. A large hierarchy can improve least privilege, but it cannot repair a weak parent, an ambiguous name or an overbroad recipient.

The complete receipt

For each operational use, preserve the EAP session reference; EMSK name; usage identifier; exact label and optional-data hash; KDF and output length; domain label; root and child names; parent-child lineage; creation and expiry; cache key and replacement event; caller identity; distribution sender, recipient and protected-channel identity; installed generation; child-protocol confirmation; and the later access or application result.

The receipt should never contain the root itself. Its purpose is to prove that separation survived every handoff around the secret.

Sources