Summary

  • RFC 1004 proposed a central “Cookie Jar” that checked which protocol peers were allowed to associate and issued a one-time key for their messages. Mills wrote it as a discussion proposal in April 1987.
  • A replay of the third establishment message could make the recipient assume a new association; the initiator would reject the resulting reply, while repeated replays might force timeouts and deny service. The author weighed that risk against the cost of another handshake.

Two gateways want to exchange routing information. An address on a packet tells each where the other claims to be; it does not tell either who sent the packet. In the Exterior Gateway Protocol, neighbors already had to establish an association before exchanging updates. D. L. Mills looked at that moment and imagined an authentication clerk with a wonderfully domestic name: the Cookie Jar. No pastries were involved. The clerk was a server that decided which two peers could talk and gave them a temporary secret to make later messages recognizable.

The April 1987 RFC 1004 described this as a proposed scheme for EGP, a proposed Dissimilar Gateway Protocol, and similar distributed protocols. Its starting world was hostile enough to include interception, alteration and retransmission of messages, but routine enough to tolerate loss and duplication. Each user had a public address and a private long-term key. A public directory listed permitted associates; the Cookie Jar held the private-key table and checked the list. If peer j was permitted for peer i, the Jar minted a random one-time key K(i,j). It wrapped a copy for each side so i could carry j's “cookie” during association setup without handing either long-term key to the network.

The Jar's power was plain: it owned the guest list and the key dispenser. Two gateways could share a wire and still lack permission to form the proposed association. After setup, the temporary key covered an encrypted checksum and sequence number on their messages. Mills wanted peers to spot spoofed or replayed traffic without encrypting the ordinary data they carried. This was a 1987 design discussion, and he was candid about its tools: a 16-bit Internet checksum had weaknesses, including invariance under word-order and byte swaps; DES was suggested as a natural encryption choice that deserved reconsideration.

A shiny name did not make weak arithmetic disappear.

The nastiest twist came from a perfectly ordinary operational move: start again. A fresh Request erased old association state and installed new key material. Mills traced a replay of the third message, the one that took the recipient into association setup. Peer j might accept the old arrival as the start of a new association and answer under a key the initiator i would reject because its sequence was wrong. One replay was unlikely to open a working unauthorized session. A rapid pile of old requests could instead make j reset and time out again and again. The attack did not need to win the conversation; it could keep forcing the introduction.

Why not demand an extra challenge and reply? Mills considered that three-way handshake and judged its overhead too expensive for the model. A determined attacker could still consume work with repeated challenges. He also noted a second race: if both peers asked the Jar for authentication at once, crossing Requests could reset each other's keys until staggered timeouts broke the tie. Even honest gateways could get stuck in the doorway. Periodic rekeying and timeout behavior belonged to the operating story, not to a decorative security appendix.

The memo explicitly invited discussion rather than announcing a standard. Its historical value lies in how closely it put authority and failure next to each other. The Jar could sanction a pair and protect a message's claimed sender, but that same establishment path created a reset surface. Every authorization design has a door; Mills sketched the hinge, the key, and the fellow who could keep ringing the bell. In the Internet's early gateway security conversation, the cookie was interesting because it could be served twice.