RFC 1004 (rfc1004) - Page 3 of 8
Distributed-protocol authentication scheme
Alternative Format: Original Text Document
RFC 1004 April 1987
The one-time key K(i,j) is generated by the Cookie Jar upon receipt
of a request from user i to associate with user j. The Cookie Jar has
access to a private table of entries in the form [A(i),K(i)], where i
ranges over the set of sanctioned users. The public directory
includes for each A(i) a list L(i) = {j1, j2, ...} of permitted
associates for i, which can be updated only by the Cookie Jar. The
Cookie Jar first checks that the requested user j is in L(i), then
rolls a random number for K(i,j) and returns this to the requestor,
which saves it and passes it along to its associate during the
connection establishment procedure.
In the diagrams that follow all fields not specifically mentioned are
unencrypted. While the natural implementation would include the
address fields of the message header in the checksum, this raises
significant difficulties, since they may be necessary to determine
the route through the network itself. As will be evident below, even
if a perpetrator could successfully tamper with the address fields in
order to cause messages to be misdelivered, the result would not be a
useful association.
The checksum field is computed by a algorithm using all the bits in
the message including the address fields in the message header, then
is ordinarily encrypted along with the sequence-number field by an
appropriate algorithm using the specified key, so that the intended
receiver is assured only the intended sender could have generated it.
In the Internet system, the natural choice for checksum is the 16-
bit, ones-complement algorithm [6], while the natural choice for
encryption is the DES algorithm [4] (see the discussion following for
further consideration on these points). The detailed procedures are
as follows:
1. The requestor i rolls a random message ID I and sends it and
the association specifier [A(i),A(j)] as a request to the Cookie
Jar. The message header includes the addresses [A(i),A(C)], where
A(C) is the address of the Cookie Jar. The following schematic
illustrates the result:
+-----------+-----------+
| A(i) | A(C) | message header
+-----------+-----------+
| I | checksum | message ID
+-----------+-----------+
| A(i) | A(j) | assoc specifier
+-----------+-----------+
2. The Cookie Jar checks the access list to determine if the
association [A(i),A(j)] is valid. If so, it rolls a random number
K(i,j) and constructs the reply below. It checksums the message,
Mills