rfc1004.txt

RFC 的详细文档！


RFC 1004                                                      April 1987


      5. Subsequent messages are all coded in the same way. As new data
      are generated the message ID is incremented, a new checksum
      computed and the message ID fields encrypted with K(i,j). The
      receiver decrypts the message ID fields with K(i,j) and discards
      the message in case of incorrect checksum or sequence number.


3. Discussion

   Since the access lists are considered public read-only, there is no
   need to validate Cookie Jar requests. A perpetrator might intercept,
   modify and replay portions of Cookie Jar replies or subsequent
   messages exchanged between the associates. However, presuming the
   perpetrator does not know the keys involved, tampered messages would
   fail the checksum test and be discarded.

   The "natural" selection of Internet checksum algorithm and DES
   encryption should be reconsidered. The Internet checksum has several
   well-known vulnerabilities, including invariance to word order and
   byte swap. In addition, the checksum field itself is only sixteen
   bits wide, so a determined perpetrator might be able to discover the
   key simply by examining all possible permutations of the checksum
   field. However, the procedures proposed herein are not intended to
   compensate for weaknesses of the checksum algorithm, since this
   vulnerability exists whether authentication is used or not. Also note
   that the encrypted fields include the sequence number as well as the
   checksum. In EGP and the proposed DGP the sequence number is a
   sixteen-bit quantity and increments for each successive message,
   which makes tampering even more difficult.

   In the intended application to EGP, DGP and similar protocols
   associations may have an indefinite lifetime, although messages may
   be sent between associates on a relatively infrequent basis.
   Therefore, every association should be rekeyed occasionally, which
   can be done by either associate simply by sending a new request to
   the Cookie Jar and following the above procedure. To protect against
   stockpiling private user keys, each user should be rekeyed
   occasionally, which is equivalent to changing passwords. The
   mechanisms for doing this are beyond the scope of this proposal.

   It is a feature of this scheme that the private user keys are not
   disclosed, except to the Cookie Jar. This is why two cookies are
   used, one for i, which only it can decrypt, and the other for j,
   decrypted first by i and then by j, which only then is valid. An
   interceptor posing as i and playing back the Cookie Jar reply to j
   will be caught, since the message will fail the checksum test. A
   perpetrator with access to both the Cookie Jar reply to i and the
   subsequent message to j will see essentially a random permutation of



Mills                                                           [Page 5]

RFC 1004                                                      April 1987


   all fields. In all except the first message to the Cookie Jar, the
   checksum field is encrypted, which makes it difficult to recover the
   original contents of the cookie fields before encryption by
   exploiting the properties of the checksum algorithm itself.

   The fact that the addresses in the message headers are included in
   the checksum protects against playbacks with modified addresses.
   However, it may still be possible to destabilize an association by
   playing back unmodified messages from prior associations. There are
   several possibilities:

      1. Replays of the Cookie Jar messages 1 and 2 are unlikely to
      cause damage, since the requestor matches both the addresses and
      once-only sequence number with its list of pending requests.

      2. Replays of message 3 may cause user j to falsely assume a new
      association. User j will return message 4 encrypted with the
      assumed session key, which might be an old one or even a currently
      valid one, but with invalid sequence number. Either way, user i
      will ignore message 4.

      3. Replays of message 4 or subsequent messages are unlikely to
      cause damage, since the sequence check will eliminate them.

   The second point above represents an issue of legitimate concern,
   since a determined attacker may stockpile message 3 interceptions and
   replay them at speed. While the attack is unlikely to succeed in
   establishing a working association, it might produce frequent
   timeouts and result in denial of service. In the Needham-Shroeder
   scheme this problem is avoided by requiring an additional challenge
   involving a message sent by user j and a reply sent by user i, which
   amounts to a three-way handshake.

   However, even if a three-way handshake were used, the additional
   protocol overhead induced by a determined attacker may still result
   in denial of service; moreover, the protocol model is inherently
   resistant to poor network performance, which has the same performance
   signature as the attacker. The conclusion is that the additional
   expense and overhead of a three-way handshake is unjustified.


4. Application to EGP and DGP

   This scheme can be incorporated in the Exterior Gateway Protocol
   (EGP) [2] and Dissimilar Gateway Protocol (DGP) [3] models by adding
   the fields above to the Request and Confirm messages in a
   straightforward way. An example of how this might be done is given in
   [3]. In order to retain the correctness of the state machine, it is



Mills                                                           [Page 6]

RFC 1004                                                      April 1987


   convenient to treat the Cookie Jar reply as a Start event, with the
   understanding that the Cookie Jar request represents an extrinsic
   event which evokes that response.

   The neighbor-acquisition strategy intended in the Dissimilar Gateway
   Protocol DGP follows the strategy in EGP. The stability of the EGP
   state machine, used with minor modifications by DGP, was verified by
   state simulation and discussed in an appendix to [2]. Either
   associate can send a Request command at any time, which causes both
   the sender and the receiver to reinitialize all state information and
   send a Confirm response. In DGP the Request operation involves the
   Cookie Jar transaction (messages 1 and 2) and then the Request
   command itself (message 3). In DGP the keys are reinitialized as well
   and each retransmission of a Request command is separately
   authenticated.

   In DGP the Request command (message 3) and all subsequent message
   exchanges assume the keys provided by the Cookie Jar. Use of any
   other keys results in checksum discrepancies and discarded messages.
   Thus the sender knows its command has been effected, at least at the
   time the response was sent. If either associate lost its state
   variables after that time, it would ignore subsequent messages and it
   (or its associate) would eventually time out and reinitiate the whole
   procedure.

   If both associates attempt to authenticate at the same time, they may
   wind up with the authentication sequences crossing in the network.
   Note that the Request message is self-authenticating, so that if a
   Request command is received by an associate before the Confirm
   response to an earlier Request command sent by that associate, the
   keys would be reset.  Thus when the subsequent Confirm response does
   arrive, it will be disregarded and the Request command resent
   following timeout. The race that results can only be broken when, due
   to staggered timeouts, the sequences do not cross in the network.
   This is a little more complicated than EGP and does imply that more
   attention must be paid to the timeouts.

   A reliable dis-association is a slippery concept, as example TCP and
   its closing sequences. However, the protocol model here is much less
   demanding. The usual way an EGP association is dissolved is when one
   associate sends a Cease command to the other, which then sends a
   Cease-ack response; however, this is specifically assumed a non-
   reliable transaction, with timeouts specified to break retry loops.
   In any case, a new Request command will erase all history and result
   in a new association as described above.

   Other than the above, the only way to reliably dis-associate is by
   timeout. In this protocol model the associates engage in a



Mills                                                           [Page 7]

RFC 1004                                                      April 1987


   reachability protocol, which requires each to send a message to the
   other from time to time. Each associate individually times out after
   a period when no messages are heard from the other.


5. Acknowledgments

   Dan Nessett and Phil Karn both provided valuable ideas and comments
   on early drafts of this report. Steve Kent and Dennis Perry both
   provided valuable advice on its review strategy.


6. References


   [1]  Kent, S.T., "Encryption-Based Protection for Interactive
        User/Computer Communication", Proc. Fifth Data Communications
        Symposium, September 1977.


   [2]  Mills, D.L., "Exterior Gateway Protocol Formal Specification",
        DARPA Network Working Group Report RFC-904, M/A-COM Linkabit,
        April 1984.


   [3]  Mills, D.L., "Dissimilar Gateway Protocol Draft Specification",
        in preparation, University of Delaware.


   [4]  National Bureau of Standards, "Data Encryption Standard",
        Federal Information Processing Standards Publication 46, January
        1977.


   [5]  Needham, R.M., and M.D. Schroeder, "Using Encryption for
        Authentication in Large Networks of Computers", Communications
        of the ACM, Vol. 21, No. 12, pp. 993-999, December 1978.


   [6]  Postel, J., "Internet Protocol", DARPA Network Working Group
        Report RFC-791, USC Information Sciences Institute, September
        1981.









Mills                                                           [Page 8]