Summary

  • RFC 3129 proposed deriving IPsec Security Association keys from Kerberos ticket session keys, replacing many pairwise long-term secrets with a centrally administered trust relationship.
  • The memo did not present KINK as a replacement for IKE: it explicitly traded IKE's ability to work without an active third party for centralized authentication, policy and computational economy.
  • Its lasting lesson is that key management complexity is redistributed, not erased; less work at each peer means more responsibility for KDC availability, realm design, time, naming and local authorization.

The most revealing equation in RFC 3129 was not cryptographic. It was organizational. A fleet that used a distinct pre-shared key for every pair of IPsec peers faced what the memo called an O(n²) distribution problem. A Kerberos realm, by contrast, could hold one long-term relationship for each principal at its Key Distribution Center. The comparison was simplified, but the diagnosis was durable: security systems fail as often from the number of relationships people must administer as from the mathematics inside a cipher.

IPsec had already separated protection from negotiation. RFC 2401 described Security Associations and the use of AH or ESP to protect IP traffic. RFC 2409 described IKE, through which two peers could authenticate, negotiate parameters and establish keying material. That peer-to-peer property was powerful. Two machines did not need a live central broker to agree on fresh keys.

But independence imposed work on every edge. Each peer needed a way to authenticate the other. Scalable public-key authentication meant certificates, trust paths and signature operations. Diffie–Hellman provided a shared secret but consumed computation and exposed responders to denial-of-service pressure. Pre-shared symmetric keys avoided certificates, yet became cumbersome when every peer required a secret with every other peer. Site policy also had to be represented and obeyed across machines that an organization might not equally trust.

RFC 3129 asked whether Kerberos could change that allocation. Kerberos V5, specified at the time by RFC 1510, already let a client authenticate to a KDC and obtain a service ticket. The ticket carried a session key known to the client and recoverable by the service. The proposed Kerberized Internet Negotiation of Keys—KINK—would use those session keys as the basis for IPsec SA keys.

This was more than substituting one handshake for another. It moved an important portion of trust from every bilateral encounter into an administrative centre. Long-term symmetric keys could live between principals and the KDC rather than between every possible pair. Public-key work, when PKINIT was used, could be paid during initial credential acquisition and amortized across tickets for many services. Policy could be concentrated where a realm administrator could manage it, rather than merely announced to every peer and trusted to survive local interpretation.

The memo was unusually candid about the price. “KINK is not a replacement for IKE,” it said in substance and in explicit wording. IKE could let two peers authenticate and exchange keys without an actively participating third party. KINK could not reproduce that property. A trusted third party was useful only where such an authority was both viable and desirable.

That limitation gives the document its historical importance. Centralization was not presented as a free simplification. It was a choice about failure domains. A KDC reduced pairwise provisioning and repeated public-key work; it also became the authority whose tickets, clocks, principal names, realm relationships and reachability shaped whether new protected relationships could begin.

The requirements show how carefully the authors tried to stop that centre from dictating every moment. Either IPsec peer had to be able to initiate, whether it possessed a service keytab or only a ticket-granting ticket. User-to-user Kerberos had to cover cases in which a responder could not decrypt an ordinary service ticket. A peer needed to participate in multiple realms. Absolute clock skew had to be handled gracefully. Most importantly, rekeying had to proceed without KDC assistance while the Kerberos session ticket remained valid.

So the KDC was not meant to sit in the data path, nor to bless each packet or each rekey. It established authenticated shared material and a bounded period of authority. The peers still had to negotiate ciphers, establish transport or tunnel mode, create AH or ESP SAs, install flow selectors, modify and delete state, and operate over IPv4 and IPv6. Local systems still decided what an authenticated identity was allowed to protect.

This distinction matters because authentication is easily mistaken for authorization. A valid Kerberos ticket can say who a principal is and provide keying material. It cannot by itself decide that the principal may build a tunnel for a particular subnet, choose a broad selector, or impersonate a gateway. Those choices remain in IPsec policy and local administration. Moving identity proof toward a KDC does not move every traffic decision there.

Nor did RFC 3129 complete the protocol. It was an Informational requirements memo. Five years later, RFC 4430 supplied the Standards Track KINK specification and explicitly treated RFC 3129 as its requirements foundation. The sequence is essential: 2001 defined the burden to be moved and the properties that must survive; 2006 described an interoperable protocol. Publication of either document does not prove broad deployment or displacement of IKE.

The surrounding standards also kept evolving. RFC 4120 later replaced the original Kerberos V5 specification. RFC 3961 separated Kerberos encryption and checksum profiles from the core protocol. RFC 4556 standardized PKINIT. IKE itself became IKEv2 in RFC 4306 and later RFC 7296. RFC 6113 generalized Kerberos pre-authentication. History did not choose one clean branch. It developed several ways to distribute trust, each with a different control surface.

RFC 3129's O(n) against O(n²) language should therefore be read as an architectural prompt, not a complete economic proof. A KDC reduces the number of pairwise long-term secrets in the simplified model. It does not remove cross-realm trust, disaster recovery, master-key protection, keytab rotation, credential renewal, clock discipline, audit, capacity planning or local access rules. It exchanges a broad mesh of bilateral obligations for a smaller number of more consequential institutions.

That exchange changes incident evidence. In a pairwise model, investigators ask which peer key or certificate path failed. In a Kerberos-backed model, they must also ask which principal obtained which ticket, through what pre-authentication, under which realm policy, for what lifetime, and whether the service then authorized the identity correctly. A KDC log can greatly strengthen attribution, yet a compromised or misconfigured authority can also issue trust at scale.

Availability changes in the same way. Existing SAs and valid tickets may outlive a temporary KDC outage, especially because RFC 3129 required local rekey during ticket validity. New credentials, expired tickets and fresh service relationships may not. The real outage boundary is thus not “KDC down means all IPsec down.” It is the interaction among cached credentials, ticket lifetime, SA lifetime, rekey rules and the point at which a peer needs central assistance again.

The memo's security considerations delivered the sober conclusion. A system built from Kerberos and IPsec inherits the union of their weaknesses. Combining two mature mechanisms does not cancel either one's failure modes. It may also create a new weakness at their junction, which the protocol would have to address.

That is why RFC 3129 belongs in a history of the Internet. It recorded a moment when protocol design recognised administration as part of cryptography. The decisive question was no longer only whether two endpoints could derive the same key. It was who had to know whom, who could impose policy, which computations repeated at the edge, and what institution would be trusted to make a large network manageable.

The KDC did not make trust disappear. It made trust legible, reusable and concentrated. That could be an enormous operational advantage. It could also turn realm governance, availability and compromise into consequences shared by many peers at once. RFC 3129's achievement was to put both sides of that bargain into the requirements before declaring the protocol complete.

Sources