home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-ciph-des-derived-00.txt < prev    next >
Text File  |  1997-07-03  |  21KB  |  661 lines

  1.  
  2. Network Working Group                                          P Metzger
  3. Internet Draft                                                [Piermont]
  4.                                                              W A Simpson
  5.                                                             [DayDreamer]
  6. expires in six months                                          July 1997
  7.  
  8.  
  9.                        The ESP DES-CBC Transform
  10.               draft-ietf-ipsec-ciph-des-derived-00.txt
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    Follows draft-simpson-esp-des1-v2-00.txt.
  16.  
  17.    This document is an Internet-Draft.  Internet Drafts are working doc-
  18.    uments of the Internet Engineering Task Force (IETF), its Areas, and
  19.    its Working Groups.  Note that other groups may also distribute work-
  20.    ing documents as Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of six
  23.    months, and may be updated, replaced, or obsoleted by other documents
  24.    at any time.  It is not appropriate to use Internet Drafts as refer-
  25.    ence material, or to cite them other than as a ``working draft'' or
  26.    ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  30.    Directories on:
  31.  
  32.       ftp.is.co.za (Africa)
  33.       nic.nordu.net (Europe)
  34.       ds.internic.net (US East Coast)
  35.       ftp.isi.edu (US West Coast)
  36.       munnari.oz.au (Pacific Rim)
  37.  
  38.    Distribution of this memo is unlimited.
  39.  
  40. Abstract
  41.  
  42.    This document describes the DES-CBC block cipher transform interface
  43.    used with the IP Encapsulating Security Payload (ESP).  It provides
  44.    compatible migration from RFC-1829.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Metzger & Simpson         expires in six months                 [Page i]
  54. DRAFT                          ESP DES-CBC                     July 1997
  55.  
  56.  
  57. 1.  Introduction
  58.  
  59.    The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi-
  60.    dentiality for IP datagrams by encrypting the payload data to be pro-
  61.    tected.  This specification describes the ESP use of the Cipher Block
  62.    Chaining (CBC) mode of the US Data Encryption Standard (DES) algo-
  63.    rithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
  64.  
  65.    The level of privacy provided by use of ESP DES-CBC in the Internet
  66.    environment is far greater than sending the datagram as cleartext.
  67.    However, in view of the current analysis of DES, it is suggested that
  68.    DES is not a good encryption algorithm for the protection of even
  69.    moderate value information for any length of time.
  70.  
  71.    For an explanation of the use of CBC mode with this cipher, see [RFC-
  72.    wwww].
  73.  
  74.    For more explanation and implementation information for DES, see
  75.    [Schneier95].
  76.  
  77.    This document assumes that the reader is familiar with the related
  78.    document "Security Architecture for the Internet Protocol"
  79.    [RFC-1825x], that defines the overall security plan for IP, and pro-
  80.    vides important background for this specification.
  81.  
  82.    In this document, the key words "MAY", "MUST", "recommended",
  83.    "required", and "SHOULD", are to be interpreted as described in
  84.    [RFC-2119].
  85.  
  86.  
  87. 1.1.  Availability
  88.  
  89.    There were a number of US patents (see [Schneier95] for listing).
  90.    All patents have expired.  Several freely available implementations
  91.    have been published world-wide.
  92.  
  93.  
  94. 1.2.  Performance
  95.  
  96.    Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90
  97.    MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium.  Other DES
  98.    speed estimates may be found at [Schneier95, page 279].  Your milage
  99.    may vary.
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108. Metzger & Simpson         expires in six months                 [Page 1]
  109. DRAFT                          ESP DES-CBC                     July 1997
  110.  
  111.  
  112. 2.  Description
  113. 2.1.  Block Size
  114.  
  115.    The US Data Encryption Standard (DES) algorithm operates on blocks of
  116.    64-bits (8 bytes).  This often requires padding before encrypting,
  117.    and subsequent removal of padding after decrypting.
  118.  
  119.    The output is the same number of bytes that are input.  This facili-
  120.    tates in-place encryption and decryption.
  121.  
  122.  
  123. 2.2.  Interaction with Authentication
  124.  
  125.    There is no known interaction of DES with any currently specified
  126.    Authenticator algorithm.  Never-the-less, any Authenticator MUST use
  127.    a separate and independently generated key.
  128.  
  129.  
  130. 3.  Initialization Vector
  131.  
  132.    DES-CBC requires an Initialization Vector (IV) that is 64-bits (8
  133.    bytes) in length [RFC-wwww].
  134.  
  135.    By default, the 64-bit IV is generated from the 32-bit ESP Sequence
  136.    Number field followed by (concatenated with) the bit-wise complement
  137.    of the same 32-bit value:
  138.  
  139.       SN || -SN
  140.  
  141.    Alternative IV generation techniques MAY be specified when dynami-
  142.    cally configured via a key management protocol.
  143.  
  144.    Security Notes:
  145.  
  146.       Using the Sequence Number provides an easy method for preventing
  147.       IV repetition, and is sufficiently robust for practical use with
  148.       the DES algorithm.  But, when used alone, cryptanalysis might be
  149.       aided by the rare serendipitous occurrence when the Sequence Num-
  150.       ber increments in exactly the same fashion as a corresponding bit
  151.       position in the first block.
  152.  
  153.       No commonly used IP (Next Header) Protocols exhibit this property.
  154.       Never-the-less, inclusion of the bit-wise complement ensures that
  155.       Sequence Number bit changes are reflected twice in the IV.
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163. Metzger & Simpson         expires in six months                 [Page 2]
  164. DRAFT                          ESP DES-CBC                     July 1997
  165.  
  166.  
  167. 4.  Keys
  168.  
  169.    DES-CBC is a symmetric secret key algorithm.  The secret DES key
  170.    shared between the communicating parties is 56-bits in length.  The
  171.    56-bit key is stored as a 64-bit (8 byte) quantity, with the least
  172.    significant bit of each byte used as a parity bit.
  173.  
  174.  
  175. 4.1.  Weak Keys
  176.  
  177.    DES has 64 known weak keys, including so-called semi-weak keys and
  178.    possibly-weak keys [Schneier95, pp 280-282] (shown in hex with parity
  179.    bits):
  180.  
  181.    0101 0101  0101 0101
  182.    1f1f 1f1f  0e0e 0e0e
  183.    e0e0 e0e0  f1f1 f1f1
  184.    fefe fefe  fefe fefe
  185.  
  186.    semi-weak key pairs:
  187.  
  188.    01fe 01fe  01fe 01fe    fe01 fe01  fe01 fe01
  189.    1fe0 1fe0  0ef1 0ef1    e0f1 e0f1  f10e f10e
  190.    01e0 01e0  01f1 01f1    e001 e001  f101 f101
  191.    1ffe 1ffe  0efe 0efe    fe1f fe1f  fe0e fe0e
  192.    011f 011f  010e 010e    1f01 1f01  0e01 0e01
  193.    e0fe e0fe  f1fe f1fe    fee0 fee0  fef1 fef1
  194.  
  195.    possibly-weak keys:
  196.  
  197.    1f1f 0101  0e0e 0101    e001 01e0  f101 01f1
  198.    011f 1f01  010e 0e01    fe1f 01e0  fe0e 01f1
  199.    1f01 011f  0e01 010e    fe01 1fe0  fe01 0ef1
  200.    0101 1f1f  0101 0e0e    e01f 1fe0  f10e 0ef1
  201.    --------------------
  202.    e0e0 0101  f1f1 0101    fe01 01fe  fe01 01fe
  203.    fefe 0101  fefe 0101    e01f 01fe  f10e 01fe
  204.    fee0 1f01  fef1 0e01    e001 1ffe  f101 0efe
  205.    e0fe 1f01  f1fe 0e01    fe1f 1ffe  fe0e 0efe
  206.                            --------------------
  207.    fee0 011f  fef1 010e    1ffe 01e0  0efe 01f1
  208.    e0fe 011f  f1fe 010e    01fe 1fe0  01fe 0ef1
  209.    e0e0 1f1f  f1f1 0e0e    1fe0 01fe  0ef1 01fe
  210.    fefe 1f1f  fefe 0e0e    01e0 1ffe  01f1 0efe
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218. Metzger & Simpson         expires in six months                 [Page 3]
  219. DRAFT                          ESP DES-CBC                     July 1997
  220.  
  221.  
  222.    fe1f e001  fe0e f101    0101 e0e0  0101 f1f1
  223.    e01f fe01  f10e fe01    1f1f e0e0  0e0e f1f1
  224.    fe01 e01f  fe01 f1e0    1f01 fee0  0e01 fef1
  225.    e001 fe1f  f101 fe0e    011f fee0  010e fef1
  226.    --------------------
  227.    01e0 e001  01f1 f101    1f01 e0fe  0e01 f1fe
  228.    1ffe e001  0efe f101    011f e0fe  010e f1fe
  229.    1fe0 fe01  0ef1 fe01    0101 fefe  0101 fefe
  230.    01fe fe01  01fe fe01    1f1f fefe  0e0e fefe
  231.                            --------------------
  232.    1fe0 e01f  0ef1 f10e    fefe e0e0  fefe f1f1
  233.    01fe e01f  01fe f10e    e0fe fee0  f1fe fef1
  234.    01e0 fe1f  01f1 fe0e    fee0 e0fe  fef1 f1fe
  235.    1ffe fe1f  0efe fe0e    e0e0 fefe  f1f1 fefe
  236.  
  237.    Implementations SHOULD take care not to select weak keys [CN94],
  238.    although the likelihood of picking one at random is negligible.
  239.  
  240.  
  241. 4.2.  Manual Key Management
  242.  
  243.    When configured manually, 64-bits (8 bytes) are configured.
  244.  
  245.    Keys with incorrect parity SHOULD be rejected by the configuration
  246.    utility, ensuring that the keys have been correctly configured.
  247.  
  248.    The 64 known weak keys SHOULD be rejected.
  249.  
  250.  
  251. 4.3.  Automated Key Management
  252.  
  253.    When configured via a Security Association management protocol,
  254.    64-bits (8 bytes) are returned for the key.
  255.  
  256.    The key manager MAY be required to generate the correct parity.
  257.    Alternatively, the least significant bit of each key byte is ignored,
  258.    or locally set to parity by the DES implementation.
  259.  
  260.    The 64 known weak keys MUST be rejected.
  261.  
  262.  
  263. 4.4.  Refresh Rate
  264.  
  265.    To prevent differential and linear cryptanalysis of collisions [RFC-
  266.    wwww], no more than 2**32 plaintext blocks SHOULD be encrypted with
  267.    the same key.  Depending on the average size of the datagrams, the
  268.    key SHOULD be changed at least as frequently as 2**30 datagrams.
  269.  
  270.  
  271.  
  272.  
  273. Metzger & Simpson         expires in six months                 [Page 4]
  274. DRAFT                          ESP DES-CBC                     July 1997
  275.  
  276.  
  277. 5.  ESP Alterations
  278. 5.1.  ESP Sequence Number
  279.  
  280.    The Sequence Number is a 32-bit (4 byte) unsigned counter.  This
  281.    field protects against replay attacks, and may also be used for syn-
  282.    chronization by stream or block-chaining ciphers.
  283.  
  284.    When configured manually, the first value sent SHOULD be a random
  285.    number.  The limited anti-replay security of the sequence of data-
  286.    grams depends upon the unpredictability of the values.
  287.  
  288.    When configured via an automated Security Association management pro-
  289.    tocol, the first value sent is 1, unless otherwise negotiated.
  290.  
  291.    Thereafter, the value is monotonically increased for each datagram
  292.    sent.  A replacement SPI SHOULD be established before the value
  293.    repeats.  That is, no more than 2**32 datagrams SHOULD be sent with
  294.    any single key.
  295.  
  296.  
  297. 5.2.  ESP Padding
  298.  
  299.    The Padding field may be zero or more bytes in length.
  300.  
  301.    Prior to encryption, this field is filled with a series of integer
  302.    values to align the Pad Length and Payload Type fields at the end of
  303.    a 64-bit (8 byte) block boundary (measured from the beginning of the
  304.    Transform Data).
  305.  
  306.    By default, each byte contains the index of the byte.  For example,
  307.    three pad bytes would contain the values 1, 2, 3.
  308.  
  309.    After decryption, this field MAY be examined for a valid series of
  310.    integer values.  Verification of the sequence of values is at the
  311.    discretion of the receiver.
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328. Metzger & Simpson         expires in six months                 [Page 5]
  329. DRAFT                          ESP DES-CBC                     July 1997
  330.  
  331.  
  332. Operational Considerations
  333.  
  334.    The specification provides only a few manually configurable parame-
  335.    ters:
  336.  
  337.    SPI
  338.       Manually configured SPIs are limited in range to aid operations.
  339.       Automated SPIs are pseudo-randomly distributed throughout the
  340.       remaining 2**32 values.
  341.  
  342.       Default: 0 (none).  Range: 256 to 65,535.
  343.  
  344.    SPI LifeTime (SPILT)
  345.       Manually configured LifeTimes are generally measured in days.
  346.       Automated LifeTimes are specified in seconds.
  347.  
  348.       Default: 32 days (2,764,800 seconds).  Maximum: 182 days
  349.       (15,724,800 seconds).
  350.  
  351.    Replay Window
  352.       Long term replay prevention requires automated configuration.
  353.       Also, some earlier implementations used pseudo-random values.
  354.       This check must only be used with those peers that have imple-
  355.       mented this feature.
  356.  
  357.       Default: 0 (checking off).  Range: 32 to 256.
  358.  
  359.    Pad Values
  360.       New implementations use verifiable values.  However, some earlier
  361.       implementations used pseudo-random values.  This check must only
  362.       be used with those peers that have implemented this feature.
  363.  
  364.       Also, some operations desire additional padding to inhibit traffic
  365.       analysis.
  366.  
  367.       Default: 0 (checking off).  Range: 7 to 255.
  368.  
  369.    Key
  370.       The 56-bit key is configured as a 64-bit quantity, with parity
  371.       included as appropriate.
  372.  
  373.    Each party configures a list of known SPIs and symmetric secret-keys.
  374.  
  375.    In addition, each party configures local policy that determines what
  376.    access (if any) is granted to the holder of a particular SPI.  For
  377.    example, a party might allow FTP, but prohibit Telnet.  Such consid-
  378.    erations are outside the scope of this document.
  379.  
  380.  
  381.  
  382.  
  383. Metzger & Simpson         expires in six months                 [Page 6]
  384. DRAFT                          ESP DES-CBC                     July 1997
  385.  
  386.  
  387. Security Considerations
  388.  
  389.    Users need to understand that the quality of the security provided by
  390.    this specification depends completely on the strength of the DES
  391.    algorithm, the correctness of that algorithm's implementation, the
  392.    security of the Security Association management mechanism and its
  393.    implementation, the strength of the key [CN94], and upon the correct-
  394.    ness of the implementations in all of the participating nodes.
  395.  
  396.    The padding bytes have a predictable value.  They provide a small
  397.    measure of tamper detection on their own block and the previous block
  398.    in CBC mode.  This makes it somewhat harder to perform splicing
  399.    attacks, and avoids a possible covert channel.  This small amount of
  400.    known plaintext does not create any problems for modern ciphers.
  401.  
  402.    At the time of writing of this document, [BS93] demonstrated a dif-
  403.    ferential cryptanalysis based chosen-plaintext attack requiring 2**47
  404.    plaintext-ciphertext block pairs, and [Matsui94] demonstrated a lin-
  405.    ear cryptanalysis based known-plaintext attack requiring only 2**43
  406.    plaintext-ciphertext block pairs.  Although these attacks are not
  407.    considered practical, they must be taken into account.
  408.  
  409.    More disturbingly, [Weiner94] has shown the design of a DES cracking
  410.    machine costing $1 Million that can crack one key every 3.5 hours.
  411.    This is an extremely practical attack.
  412.  
  413.    One or two blocks of known plaintext suffice to recover a DES key.
  414.    Because IP datagrams typically begin with a block of known and/or
  415.    guessable header text, frequent key changes will not protect against
  416.    this attack.
  417.  
  418.  
  419. Changes from RFC-1829:
  420.  
  421.    This specification results in the same default bits-on-the-wire as
  422.    the 32-bit IV calculation method of RFC-1829.  The 32-bit field is
  423.    semantically identical to a Sequence Number when implemented as a
  424.    counter (the recommended method).
  425.  
  426.    The 64-bit explicit IV option is deprecated, as no hardware manufac-
  427.    turers were found that required it.  It does not meet 64-bit field
  428.    alignment expectations of IPv6, it is a cryptographically weaker con-
  429.    struct than a calculated IV [Bellovin96], and it conflicts with the
  430.    use of a Sequence Number immediately following the SPI.
  431.  
  432.    Padding is a known series of integers, that may be checked upon
  433.    receipt.
  434.  
  435.  
  436.  
  437.  
  438. Metzger & Simpson         expires in six months                 [Page 7]
  439. DRAFT                          ESP DES-CBC                     July 1997
  440.  
  441.  
  442.    Many implementation details by Karn were found to be common to all
  443.    ESP Ciphers, and are awaiting consolidation in the ESP specification.
  444.  
  445.    Added an operational section.
  446.  
  447.    Updated acknowledgements, references, and contacts.
  448.  
  449.    Reorganized according to the new "road map" document.
  450.  
  451.  
  452. Acknowledgements
  453.  
  454.    The basic field naming and layout is based on "swIPe" [IBK93, IB93].
  455.  
  456.    Participants in the IP Security Working Group modified this to a
  457.    variable number of variable length fields.  After a digression span-
  458.    ning 4 years, actual implementors mandated a return to these fewer
  459.    well-known fields.
  460.  
  461.    Some of the text of this specification was derived from work by Ran-
  462.    dall Atkinson for the SIP, SIPP, and IPv6 Working Groups.
  463.  
  464.    Perry Metzger provided the original Security Considerations text,
  465.    some of which is distributed throughout the document.
  466.  
  467.    William Allen Simpson was responsible for the name and semantics of
  468.    the SPI, the IV calculation technique(s), editing and formatting.
  469.  
  470.    The use of known padding values was suggested in various forms by
  471.    Robert Baldwin, Phil Karn, and David Wagner.  This specification uses
  472.    Self-Describing-Padding [RFC-1570].
  473.  
  474.    Robert Baldwin, Steve Bellovin, Steve Deering, Karl Fox, Charles
  475.    Lynn, Cheryl Madson, Craig Metz, Dave Mihelcic, Jeffrey Schiller,
  476.    Norman Shulman and David Wagner provided useful critiques of earlier
  477.    versions of this document.
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493. Metzger & Simpson         expires in six months                 [Page 8]
  494. DRAFT                          ESP DES-CBC                     July 1997
  495.  
  496.  
  497. References
  498.  
  499.    [Bellovin96]
  500.             Bellovin, S., "Problem Areas for the IP Security Protocols",
  501.             Proceedings of the Sixth Usenix Security Symposium, July
  502.             1996.
  503.  
  504.    [BS93]   Biham, E., and Shamir, A., "Differential Cryptanalysis of
  505.             the Data Encryption Standard", Berlin: Springer-Verlag,
  506.             1993.
  507.  
  508.    [CN94]   Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
  509.             Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
  510.             253-280, July 1994.
  511.  
  512.    [FIPS-46]
  513.             US National Bureau of Standards, "Data Encryption Standard",
  514.             Federal Information Processing Standard (FIPS) Publication
  515.             46, January 1977.
  516.  
  517.    [FIPS-46-1]
  518.             US National Bureau of Standards, "Data Encryption Standard",
  519.             Federal Information Processing Standard (FIPS) Publication
  520.             46-1, January 1988.
  521.  
  522.    [FIPS-74]
  523.             US National Bureau of Standards, "Guidelines for Implement-
  524.             ing and Using the Data Encryption Standard", Federal Infor-
  525.             mation Processing Standard (FIPS) Publication 74, April
  526.             1981.
  527.  
  528.    [FIPS-81]
  529.             US National Bureau of Standards, "DES Modes of Operation"
  530.             Federal Information Processing Standard (FIPS) Publication
  531.             81, December 1980.
  532.  
  533.    [IB93]   Ioannidis, J., and Blaze, M., "The Architecture and Imple-
  534.             mentation of Network-Layer Security Under Unix", Proceedings
  535.             of the Fourth Usenix Security Symposium, Santa Clara Cali-
  536.             fornia, October 1993.
  537.  
  538.    [IBK93]  Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network-
  539.             Layer Security for IP", Presentation at the 26th Internet
  540.             Engineering Task Force, Columbus Ohio, March 1993.
  541.  
  542.    [Matsui94]
  543.             Matsui, M., "Linear Cryptanalysis method for DES Cipher,"
  544.             Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin:
  545.  
  546.  
  547.  
  548. Metzger & Simpson         expires in six months                 [Page 9]
  549. DRAFT                          ESP DES-CBC                     July 1997
  550.  
  551.  
  552.             Springer-Verlag, 1994.
  553.  
  554.    [RFC-1570]
  555.             Simpson, W., "PPP LCP Extensions", DayDreamer, January 1994.
  556.  
  557.    [RFC-1825x]
  558.             Atkinson, R., "Security Architecture for the Internet Proto-
  559.             col", Naval Research Laboratory, July 1995.
  560.  
  561.    [RFC-1827x]
  562.             Simpson, W., "IP Encapsulating Security Protocol (ESP) for
  563.             implementors", work in progress.
  564.  
  565.    [RFC-2119]
  566.             Bradner, S., "Key words for use in RFCs to Indicate Require-
  567.             ment Levels", BCP 14, Harvard University, March 1997.
  568.  
  569.    [RFC-wwww]
  570.             Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", work
  571.             in progress.
  572.  
  573.    [Schneier95]
  574.             Schneier, B., "Applied Cryptography Second Edition", John
  575.             Wiley & Sons, New York, NY, 1995.  ISBN 0-471-12845-7.
  576.  
  577.    [Weiner94]
  578.             Wiener, M.J., "Efficient DES Key Search", School of Computer
  579.             Science, Carleton University, Ottawa, Canada, TR-244, May
  580.             1994.  Presented at the Rump Session of Crypto '93.
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603. Metzger & Simpson         expires in six months                [Page 10]
  604. DRAFT                          ESP DES-CBC                     July 1997
  605.  
  606.  
  607. Contacts
  608.  
  609.    Comments about this document should be discussed on the ipsec@tis.com
  610.    mailing list.
  611.  
  612.    Questions about this document can also be directed to:
  613.  
  614.       Perry Metzger
  615.       Piermont Information Systems Inc.
  616.       160 Cabrini Blvd., Suite #2
  617.       New York, NY  10033
  618.  
  619.           perry@piermont.com
  620.  
  621.  
  622.       William Allen Simpson
  623.       DayDreamer
  624.       Computer Systems Consulting Services
  625.       1384 Fontaine
  626.       Madison Heights, Michigan  48071
  627.  
  628.           wsimpson@UMich.edu
  629.           wsimpson@GreenDragon.com (preferred)
  630.           bsimpson@MorningStar.com
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658. Metzger & Simpson         expires in six months                [Page 11]
  659.  
  660.  
  661.