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
