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-cast-div-00.txt < prev    next >
Text File  |  1997-08-02  |  11KB  |  385 lines

  1.  
  2. Network Working Group                                        W A Simpson
  3. Internet Draft                                              [DayDreamer]
  4. expires in six months                                          July 1997
  5.  
  6.  
  7.                     The ESP CAST5-128-CBC Transform
  8.                  draft-ietf-ipsec-ciph-cast-div-00.txt
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This document is an Internet-Draft.  Internet Drafts are working doc-
  14.    uments of the Internet Engineering Task Force (IETF), its Areas, and
  15.    its Working Groups.  Note that other groups may also distribute work-
  16.    ing documents as Internet Drafts.
  17.  
  18.    Internet Drafts are draft documents valid for a maximum of six
  19.    months, and may be updated, replaced, or obsoleted by other documents
  20.    at any time.  It is not appropriate to use Internet Drafts as refer-
  21.    ence material, or to cite them other than as a ``working draft'' or
  22.    ``work in progress.''
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  26.    Directories on:
  27.  
  28.       ftp.is.co.za (Africa)
  29.       nic.nordu.net (Europe)
  30.       ds.internic.net (US East Coast)
  31.       ftp.isi.edu (US West Coast)
  32.       munnari.oz.au (Pacific Rim)
  33.  
  34.    Distribution of this memo is unlimited.
  35.  
  36. Abstract
  37.  
  38.    This document describes the CAST5-128-CBC block cipher transform
  39.    interface used with the IP Encapsulating Security Payload (ESP).  It
  40.    provides a full-sized 128-bit key, with a more secure derived ini-
  41.    tialization variable, and a more efficient smaller datagram size.
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Simpson                   expires in six months                 [Page i]
  54. DRAFT                         ESP CAST-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 with CAST5-128.
  63.  
  64.    The CAST Design Procedure was originally developed by Carlisle Adams
  65.    and Stafford Travares at Queen's University, Kingston, Ontario,
  66.    Canada.  Subsequent enhancements have been made over the years by
  67.    Carlisle Adams and Michael Wiener of Entrust Technologies.  CAST5-128
  68.    is the result of applying the CAST Design Procedure as outlined in
  69.    [RFC-2144].
  70.  
  71.    For an explanation of the use of CBC mode with this cipher, see [RFC-
  72.    wwww].
  73.  
  74.    This document assumes that the reader is familiar with the related
  75.    document "Security Architecture for the Internet Protocol"
  76.    [RFC-1825x], that defines the overall security plan for IP, and pro-
  77.    vides important background for this specification.
  78.  
  79.    In this document, the key words "MAY", "MUST", "recommended",
  80.    "required", and "SHOULD", are to be interpreted as described in
  81.    [RFC-2119].
  82.  
  83.  
  84. 1.1.  Availability
  85.  
  86.    There are a number of patents.  Unfortunately, the CAST authors have
  87.    not listed them in their drafts, as required as by the IETF.  Watch
  88.    this space.
  89.  
  90.  
  91. 1.2.  Performance
  92.  
  93.    It is speculated that CAST5-128 runs approximately the same speed as
  94.    a highly optimized DES implementation.  This is based on a non-
  95.    optimized C++ implementation.  It is hoped that this can be tuned to
  96.    give even higher performance.
  97.  
  98.    The following performance tests were run on a Pentium 90 MHz running
  99.    the Windows NT operating system using 20 Kbyte buffers, and do not
  100.    include file I/O.  The DES-CBC implementation was not optimized for a
  101.    32-bit environment.
  102.  
  103.    CAST5-64 bit key 12 round CBC encryption ..... 21,120,000 bits/sec
  104.    DES-CBC encryption ............................ 4,032,000 bits/sec
  105.  
  106.  
  107.  
  108. Simpson                   expires in six months                 [Page 1]
  109. DRAFT                         ESP CAST-CBC                     July 1997
  110.  
  111.  
  112.    There is no data available on a full-sized 128-bit key with 16
  113.    rounds.  Watch this space.
  114.  
  115.    For comparison, Phil Karn has tuned DES-CBC software to achieve 10.45
  116.    Mbps with a 90 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pen-
  117.    tium.  Your milage may vary.
  118.  
  119.  
  120. 2.  Description
  121. 2.1.  Block Size
  122.  
  123.    The CAST5-128 algorithm operates on blocks of 64-bits (8 bytes).
  124.    This often requires padding before encrypting, and subsequent removal
  125.    of padding after decrypting.
  126.  
  127.    The output is the same number of bytes that are input.  This facili-
  128.    tates in-place encryption and decryption.
  129.  
  130.  
  131. 2.2.  Rounds
  132.  
  133.    The algorithm MUST use the full 16 rounds.
  134.  
  135.  
  136. 2.3.  Interaction with Authentication
  137.  
  138.    There is no known interaction of CAST5-128 with any currently speci-
  139.    fied Authenticator algorithm.
  140.  
  141.  
  142. 3.  Initialization Vector
  143.  
  144.    CAST5-128-CBC requires an Initialization Vector (IV) that is 64-bits
  145.    (8 bytes) in length [RFC-wwww].
  146.  
  147.    By default, the 64-bit IV is generated from the 32-bit Security
  148.    Parameters Index (SPI) field followed by (concatenated with) the
  149.    32-bit Sequence Number (SN) field.  Then, the bit-wise complement of
  150.    the 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits
  151.    (SPI):
  152.  
  153.       (SPI ^ -SN) || SN
  154.  
  155.    Alternative IV generation techniques MAY be specified when dynami-
  156.    cally configured via a key management protocol.
  157.  
  158.    Security Notes:
  159.  
  160.  
  161.  
  162.  
  163. Simpson                   expires in six months                 [Page 2]
  164. DRAFT                         ESP CAST-CBC                     July 1997
  165.  
  166.  
  167.       Incorporating the ESP Security Parameters Index (SPI) and the
  168.       anti-replay ESP Sequence Number (SN) together can provide greater
  169.       uniqueness and mutual protection between the first block and the
  170.       ESP header.  Modification of the SPI to alter the decryption
  171.       key(s) will prevent correct decryption of the first block.
  172.  
  173.       Using the Sequence Number (SN) provides an easy method for pre-
  174.       venting IV repetition, and is sufficiently robust for practical
  175.       use with the CAST5-128 algorithm.  Inclusion of the bit-wise com-
  176.       plement of SN ensures that bit changes are reflected twice in the
  177.       IV.
  178.  
  179.  
  180. 4.  Keys
  181.  
  182.    CAST5-128 is a symmetric secret key algorithm.  The secret CAST5-128
  183.    key shared between the communicating parties is 128-bits in length.
  184.  
  185.    Although CAST5-128 can be used with shorter keys, these other keys
  186.    sizes are not conformant with this specification.
  187.  
  188.  
  189. 4.1.  Weak Keys
  190.  
  191.    CAST5-128 has no known weak keys.
  192.  
  193.  
  194. 4.2.  Refresh Rate
  195.  
  196.    CAST5-128 is theorized to be immune to differential and linear crypt-
  197.    analysis.
  198.  
  199.  
  200. 5.  ESP Alterations
  201. 5.1.  ESP Sequence Number
  202.  
  203.    The Sequence Number is a 32-bit (4 byte) unsigned counter.  This
  204.    field protects against replay attacks, and may also be used for syn-
  205.    chronization by stream or block-chaining ciphers.
  206.  
  207.    When configured manually, the first value sent SHOULD be a random
  208.    number.
  209.  
  210.    When configured via an automated Security Association management pro-
  211.    tocol, the first value sent is 1, unless otherwise negotiated.
  212.  
  213.    Thereafter, the value is monotonically increased for each datagram
  214.    sent.  A replacement SPI SHOULD be established before the value
  215.  
  216.  
  217.  
  218. Simpson                   expires in six months                 [Page 3]
  219. DRAFT                         ESP CAST-CBC                     July 1997
  220.  
  221.  
  222.    repeats.  That is, less than 2**32 datagrams SHOULD be sent with any
  223.    single key.
  224.  
  225.  
  226. Operational Considerations
  227.  
  228.    The specification provides only a few manually configurable parame-
  229.    ters:
  230.  
  231.    SPI
  232.       Manually configured SPIs are limited in range to aid operations.
  233.       Automated SPIs are pseudo-randomly distributed throughout the
  234.       remaining 2**32 values.
  235.  
  236.       Default: 0 (none).  Range: 256 to 65,535.
  237.  
  238.    SPI LifeTime (SPILT)
  239.       Manually configured LifeTimes are generally measured in days.
  240.       Automated LifeTimes are specified in seconds.
  241.  
  242.       Default: 32 days (2,764,800 seconds).  Maximum: 182 days
  243.       (15,724,800 seconds).
  244.  
  245.    Replay Window
  246.       Default: 0 (checking off).  Range: 32 to 256.
  247.  
  248.    Pad Values
  249.       Default: 7 (checking on).  Range: 7 to 255.
  250.  
  251.    Key
  252.       The 128-bit key is configured as required.
  253.  
  254.    Each party configures a list of known SPIs and symmetric secret-keys.
  255.  
  256.    In addition, each party configures local policy that determines what
  257.    access (if any) is granted to the holder of a particular SPI.  For
  258.    example, a party might allow FTP, but prohibit Telnet.  Such consid-
  259.    erations are outside the scope of this document.
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273. Simpson                   expires in six months                 [Page 4]
  274. DRAFT                         ESP CAST-CBC                     July 1997
  275.  
  276.  
  277. Security Considerations
  278.  
  279.    Users need to understand that the quality of the security provided by
  280.    this specification depends completely on the strength of the CAST
  281.    algorithm, the correctness of that algorithm's implementation, the
  282.    security of the Security Association management mechanism and its
  283.    implementation, the strength of the key, and upon the correctness of
  284.    the implementations in all of the participating nodes.
  285.  
  286.  
  287. Acknowledgements
  288.  
  289.    The basic field naming and layout is based on "swIPe" [IBK93, IB93].
  290.  
  291.    Some of the text of this specification was derived from work by Roy
  292.    Pereira and Greg Carter.
  293.  
  294.    William Allen Simpson was responsible for the name and semantics of
  295.    the SPI, the IV calculation technique(s), editing and formatting.
  296.  
  297.  
  298. References
  299.  
  300.    [IB93]   Ioannidis, J., and Blaze, M., "The Architecture and Imple-
  301.             mentation of Network-Layer Security Under Unix", Proceedings
  302.             of the Fourth Usenix Security Symposium, Santa Clara Cali-
  303.             fornia, October 1993.
  304.  
  305.    [IBK93]  Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network-
  306.             Layer Security for IP", Presentation at the 26th Internet
  307.             Engineering Task Force, Columbus Ohio, March 1993.
  308.  
  309.    [RFC-1825x]
  310.             Atkinson, R., "Security Architecture for the Internet Proto-
  311.             col", Naval Research Laboratory, July 1995.
  312.  
  313.    [RFC-1827x]
  314.             Simpson, W., "IP Encapsulating Security Protocol (ESP) for
  315.             implementors", work in progress.
  316.  
  317.    [RFC-2119]
  318.             Bradner, S., "Key words for use in RFCs to Indicate Require-
  319.             ment Levels", BCP 14, Harvard University, March 1997.
  320.  
  321.    [RFC-2144]
  322.             Adams, C., "The CAST-128 Encryption Algorithm", May 1997.
  323.  
  324.  
  325.  
  326.  
  327.  
  328. Simpson                   expires in six months                 [Page 5]
  329. DRAFT                         ESP CAST-CBC                     July 1997
  330.  
  331.  
  332.    [RFC-wwww]
  333.             Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", work
  334.             in progress.
  335.  
  336.  
  337.  
  338. Contacts
  339.  
  340.    Comments about this document should be discussed on the ipsec@tis.com
  341.    mailing list.
  342.  
  343.    Questions about this document can also be directed to:
  344.  
  345.       Perry Metzger
  346.       Piermont Information Systems Inc.
  347.       160 Cabrini Blvd., Suite #2
  348.       New York, NY  10033
  349.  
  350.           perry@piermont.com
  351.  
  352.  
  353.       William Allen Simpson
  354.       DayDreamer
  355.       Computer Systems Consulting Services
  356.       1384 Fontaine
  357.       Madison Heights, Michigan  48071
  358.  
  359.           wsimpson@UMich.edu
  360.           wsimpson@GreenDragon.com (preferred)
  361.           bsimpson@MorningStar.com
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383. Simpson                   expires in six months                 [Page 6]
  384.  
  385.