Summary

  • RFC 2412's three-message OAKLEY example allowed the signatures to be validated and the KEYID to be marked authenticated while the Diffie–Hellman shared value was still marked uncomputed.
  • The RFC therefore distinguished proof of communication from key calculation. Neither one, by itself, proved correct key binding, two-sided Security Association installation, protected traffic or an application result.

There is a sentence in RFC 2412 that removes a great deal of comfort from the word authenticated.

In the aggressive OAKLEY example, two parties exchange identities, nonces, algorithm choices and Diffie–Hellman half-keys. Each party signs the relevant transcript. The signatures can become a “proof of communication,” something that may be recorded and later shown to a third party. Three messages can complete the exchange.

Then the RFC says the keying material implied by the group exponentials is not needed to complete it.

An implementation may retain its private exponent and the peer's public exponential, mark the keying material uncomputed, and calculate the shared value later. In the processing outline, the initiator may postpone (g^y)^x until after sending its last reply. It validates the responder's signature, stores the selected state and marks the KEYID authenticated. The responder, after validating that final signature, marks the key authenticated and should compute g^xy and associate it with the KEYID.

The exchange has crossed an authentication boundary. The shared secret may not yet have crossed a computation boundary.

That was not a contradiction hidden in an implementation. It was a timing choice described by the protocol. OAKLEY authenticated the binding of identities to the advertised exponentials; it did not require authentication itself to be performed by encrypting with the resulting Diffie–Hellman value. RFC 2412 even states the general rule before the example: the two parties need not compute the shared exponentials before authentication.

The distinction can sound academic until the pieces are named carefully.

The cookies form the KEYID, a reusable name for keying material. The RFC gives those cookies a second, weaker role in address validation and anti-clogging. The secret material named by the KEYID is sKEYID, derived in the example from the nonces, g^xy and the cookies. A name can therefore exist before the material it names has been calculated. An authenticated name can exist before that calculation. A signed transcript can prove that two identities participated in a particular exchange without proving that either endpoint has already installed a usable traffic-protection state.

Names, evidence and material occupy different layers.

This matters because operational systems like to compress state. A management interface has room for a green light, not a dissertation. A log wants one verb: authenticated, established, ready. An application wants to know whether it may send. If the implementation chooses the earliest true word and presents it as the final truth, it turns a local optimization into a remote promise.

OAKLEY's deferral could be perfectly sensible. Modular exponentiation was expensive, especially in the late 1990s. Keeping it out of the last-message critical path could reduce apparent handshake latency. The peer still received the same signed fields. Nothing in the wire transcript had to reveal whether the calculation occurred just before or just after the final send.

But the saved work became saved obligation. The implementation had to retain the correct private exponent, the peer's public value, the chosen group, both cookies, both nonces, the identities and the selected algorithms. It had to validate the received value, perform the exponentiation, derive the right material and bind it to the right KEYID. If a process crashed, state expired, a handle was reused or an upper layer mistook “authenticated” for “ready,” the transcript could remain perfectly intelligible while the usable secret never appeared.

This is why a good audit trail cannot use the signed message as a substitute for a computation receipt.

A transcript receipt says that the expected signature validated over the expected fields. An authentication-state receipt says that local software promoted a named exchange. A validation receipt says that the peer's group element passed the checks required by the applicable protocol generation. A computation receipt says that the shared value and derived material were actually calculated. A binding receipt joins those bytes to the intended peer identities, algorithms and KEYID. An installation receipt shows that the correct runtime Security Association received them. A packet receipt shows that protected traffic was accepted.

An outcome receipt belongs to the service that the security machinery was meant to support.

Each can be true while the next remains unknown.

The responder's wording makes the boundary especially visible. After a valid final signature, it marks the key authenticated; it “should compute” g^xy and associate it with the KEYID. That sequence should not be inflated into a claim that both sides installed identical state. RFC 2412 does not describe a production telemetry schema, a crash-recovery record or a two-sided installation acknowledgement. It also does not report which products used deferred computation, how often they used it or whether a real failure resulted. The history is in the permission and the state ordering, not in an invented deployment story.

The safety of the later computation also depended on its inputs. RFC 2412 advised implementations not to offer or accept certain degenerate modular-exponentiation values and required strong randomness for nonces, cookies and exponents. Its published errata corrects terminology about safe primes and Sophie Germain primes without changing the deferred-computation mechanism.

Later standards made the validation boundary more explicit. RFC 6989 addressed Diffie–Hellman public-key validation in IKEv2, including groups with small subgroups, and required an invalid Key Exchange payload to be rejected rather than used in creating an IKE SA. That document does not retroactively prove what an OAKLEY or IKEv1 implementation checked. It does reinforce the evidentiary sequence: receiving a value is not authority to derive from it; successful parsing is not successful validation.

OAKLEY's ideas did not remain isolated. RFC 2409 combined ISAKMP and OAKLEY material into IKEv1. Its Aggressive Mode likewise allowed the last payload to remain unprotected so that exponentiation could be postponed until the exchange was complete. Its key schedule nevertheless depended on the actual Diffie–Hellman shared value. The exchange might leave the wire before the expensive calculation finished, but the resulting protection could not be manufactured from the completion label.

The later IKEv2 line reorganized the machinery. RFC 4306, RFC 5996 and then RFC 7296 replaced generations of the earlier design. RFC 7296 derives SKEYSEED from the nonces and the ephemeral Diffie–Hellman shared secret, then expands distinct keys for derivation, authentication and encryption. It also preserves a useful state distinction of its own: authentication may establish the IKE SA while the Child SA or configuration request still fails.

That is not the same state machine as RFC 2412, and it should not be presented as one. It is evidence that protocol evolution continued to separate security control state from the later state it enables. Authentication can be complete at one layer while a subordinate data path remains absent.

The document history also warns against turning publication into deployment. RFC 2412 was Informational. Its status notice said that it did not specify an Internet standard. RFC 2409 was standards track, IKEv2 later obsoleted IKEv1, algorithm requirements changed, and RFC 9395 eventually deprecated IKEv1 and several obsolete algorithms. None of those documentary acts reached backward into every device to erase its code. Current guidance and historical behavior are different facts, just as an authenticated transcript and a computed secret are different facts.

This is where Lu Heng's Running-Code Primacy provides a useful analytical discipline. A status word on a page—or in a dashboard—cannot substitute for an inspectable state transition in the machine. Reality layers are not competing stories from which an institution chooses the most convenient. They are dependent facts. The transcript exists. The signature validates. The public value passes checks. The secret is computed. The key is bound. The SA is installed. The packet passes. The application succeeds.

Minimum Initial Specification supplies the constructive half of that argument. Independent implementations needed a common transcript, common derivation rules and common meanings for the values on the wire. They did not necessarily need a universal scheduler telling each endpoint exactly which CPU instruction must execute before the final send. RFC 2412 allowed a local timing decision while preserving the shared protocol.

Local freedom, however, does not erase accountability. The implementer choosing deferral controls the hidden interval between authenticated state and computed material. It therefore owns the duty to expose that interval accurately, retain its inputs safely and recover or fail without lending a stronger meaning to a weaker receipt. The application that bears the failure should not have to infer those facts from a green “authenticated” badge.

The lasting lesson of OAKLEY's uncomputed state is not that authentication was hollow. The signatures proved something important. They bound named parties to a particular exchange. The lesson is that strong evidence becomes dangerous when it is asked to prove a different event.

The exchange was authenticated. The shared secret still had to be computed. The Security Association still had to be bound and installed. The packets still had to pass. The service still had to work.

Protocol history becomes useful when it preserves every one of those verbs.

Sources