rfc1004.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         D.L. Mills
Request for Comments:  1004                       University of Delaware
                                                              April 1987


              A Distributed-Protocol Authentication Scheme


Status of this Memo

   The purpose of this RFC is to focus discussion on authentication
   problems in the Internet and possible methods of solution.  The
   proposed solutions this document are not intended as standards for
   the Internet at this time.  Rather, it is hoped that a general
   consensus will emerge as to the appropriate solution to
   authentication problems, leading eventually to the adoption of
   standards.  Distribution of this memo is unlimited.


1. Introduction and Overview

   This document suggests mediated access-control and authentication
   procedures suitable for those cases when an association is to be set
   up between multiple users belonging to different trust environments,
   but running distributed protocols like the existing Exterior Gateway
   Protocol (EGP) [2], proposed Dissimilar Gateway Protocol (DGP) [3]
   and similar protocols. The proposed prcedures are evolved from those
   described by Needham and Shroeder [5], but specialized to the
   distributed, multiple-user model typical of these protocols.

   The trust model and threat environment are identical to that used by
   Kent and others [1]. An association is defined as the end-to-end
   network path between two users, where the users themselves are
   secured, but the path between them is not. The network may drop,
   duplicate or deliver messages with errors. In addition, it is
   possible that a hostile user (host or gateway) might intercept,
   modify and retransmit messages. An association is similar to the
   traditional connection, but without the usual connection requirements
   for error-free delivery.  The users of the association are sometimes
   called associates.

   The proposed procedures require each association to be assigned a
   random session key, which is provided by an authentication server
   called the Cookie Jar. The procedures are designed to permit only
   those associations sanctioned by the Cookie Jar while operating over
   arbitrary network topologies, including non-secured networks and
   broadcast-media networks, and in the presence of hostile attackers.
   However, it is not the intent of these procedures to hide the data



Mills                                                           [Page 1]

RFC 1004                                                      April 1987


   (except for private keys) transmitted via these networks, but only to
   authenticate messages to avoid spoofing and replay attacks.

   The procedures are intended for distributed systems where each user i
   runs a common protocol automaton using private state variables for
   each of possibly several associations simultaneously, one for each
   user j. An association is initiated by interrogating the Cookie Jar
   for a one-time key K(i,j), which is used to encrypt the checksum
   which authenticates messages exchanged between the users. The
   initiator then communicates the key to its associate as part of a
   connection establishment procedure such as described in [3].

   The information being exchanged in this protocol model is largely
   intended to converge a distributed data base to specified (as far as
   practical) contents, and does not ordinarily require a reliable
   distribution of event occurances, other than to speed the convergence
   process. Thus, the model is intrinsically resistant to message loss
   or duplication. Where important, sequence numbers are used to reduce
   the impact of message reordering. The model assumes that associations
   between peers, once having been sanctioned, are maintained
   indefinitely.  The exception when an association is broken may be due
   to a crash, loss of connectivity or administrative action such as
   reconfiguration or rekeying. Finally, the rate of information
   exchange is specifically designed to be much less than the nominal
   capabilities of the network, in order to keep overheads low.


2. Procedures

   Each user i is assigned a public address A(i) and private key K(i) by
   an out-of-band procedure beyond the scope of this discussion. The
   address can take many forms: an autonomous system identifier [2], an
   Internet address [6] or simply an arbitrary name. However, no matter
   what form it takes, every message is presumed to carry both the
   sender and receiver addresses in its header. Each address and its
   access-control list is presumed available in a public directory
   accessable to all users, but the private key is known only to the
   user and Cookie Jar and is not disclosed in messages exchanged
   between users or between users and the Cookie Jar.

   An association between i and j is identified by the bitstring
   consisting of the catenation of the addresses A(i) and A(j), together
   with a one-time key K(i,j), in the form [A(i),A(j),K(i,j)]. Note that
   the reciprocal association [A(j),A(i),K(j,i)] is distinguished only
   by which associate calls the Cookie Jar first. It is the intent in
   the protocol model that all state variables and keys relevant to a
   previous association be erased when a new association is initiated
   and no caching (as suggested in [5]) is allowed.



Mills                                                           [Page 2]

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                                                           [Page 3]

RFC 1004                                                      April 1987


      encrypts the j cookie field with K(j), then encrypts it and the
      other fields indicated with K(i) and finally sends the reply:

      +-----------+-----------+
      |   A(C)    |   A(i)    |       message header
      +-----------+-----------+
      |     I     | checksum  |       message ID (encrypt K(i))
      +-----------+-----------+
      |   K(i,j)  |                   i cookie (encrypt K(i))
      +-----------+
      |   K(i,j)  |                   j cookie (encrypt K(j)K(i))
      +-----------+

      3. Upon receipt of the reply the requestor i decrypts the
      indicated fields, saves the (encrypted) j cookie field and copies
      the i cookie field to the j cookie field, so that both cookie
      fields are now the original K(i,j) provided by the Cookie Jar.
      Then it verifies the checksum and matches the message ID with its
      list of outstanding requests, retaining K(i,j) for its own use. It
      then rolls a random number X for the j cookie field (to confuse
      wiretappers) and another I' for the (initial) message ID, then
      recomputes the checksum.  Finally, it inserts the saved j cookie
      field in the i cookie field, encrypts the message ID fields with
      K(i,j) and sends the following message to its associate:

      +-----------+-----------+
      |   A(i)    |   A(j)    |       message header
      +-----------+-----------+
      |     I'    | checksum  |       message ID (encrypt K(i,j))
      +-----------+-----------+
      |  K(i,j)   |                   i cookie (encrypt K(j))
      +-----------+
      |     X     |                   j cookie (noise)
      +-----------+

      4. Upon receipt of the above message the associate j decrypts the
      i cookie field, uses it to decrypt the message ID fields and
      verifies the checksum, retaining the I' and K(i,j) for later use.
      Finally, it rolls a random number J' as its own initial message
      ID, inserts it and the checksum in the confirm message, encrypts
      the message ID fields with K(i,j) and sends the message:

      +-----------+-----------+
      |   A(j)    |   A(i)    |       message header
      +-----------+-----------+
      |     J'    | checksum  |       message ID (encrypt K(i,j))
      +-----------+-----------+




Mills                                                           [Page 4]