RFC 1004 (rfc1004) - Page 3 of 8

Distributed-protocol authentication scheme

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