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-rc5-cbc-00.txt < prev    next >
Text File  |  1997-07-02  |  9KB  |  275 lines
  1.  
  2. Internet Engineering Task Force                            Roy Pereira
  3. IP Security Working Group                         TimeStep Corporation
  4. Internet Draft                                           R. W. Baldwin
  5. Expires in six months                          RSA Data Security, Inc.
  6.                                                           July 2, 1997
  7.  
  8.  
  9.  
  10.                       The ESP RC5-CBC Algorithm
  11.                 <draft-ietf-ipsec-ciph-rc5-cbc-00.txt>
  12.  
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This document is a submission to the IETF Internet Protocol
  18.    Security (IPSEC) Working Group. Comments are solicited and should
  19.    be addressed to the working group mailing list (ipsec@tis.com) or
  20.    to the editor.
  21.  
  22.    This document is an Internet-Draft.  Internet Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its areas,
  24.    and its working Groups. Note that other groups may also distribute
  25.    working documents as Internet Drafts.
  26.  
  27.    Internet-Drafts draft documents are valid for a maximum of six
  28.    months and may be updated, replaced, or obsolete by other documents
  29.    at any time. It is inappropriate to use Internet-Drafts as
  30.    reference material or to cite them other than as "work in
  31.    progress."
  32.  
  33.    To learn the current status of any Internet-Draft, please check the
  34.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  35.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  36.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  37.    ftp.isi.edu (US West Coast).
  38.  
  39.    Distribution of this memo is unlimited.
  40.  
  41. Abstract
  42.  
  43.    This document describes the RC5 block cipher algorithm as to be
  44.    used with the IPSec Encapsulating Security Payload (ESP).
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. R. Pereira, B. Baldwin                                        [Page 1]
  56.  
  57. Internet Draft        The ESP RC5-CBC Algorithm           July 2, 1997
  58.  
  59.  
  60. Table of Contents
  61.  
  62.    1. Introduction...................................................2
  63.      1.1 Specification of Requirements...............................2
  64.    2. Cipher Algorithm...............................................2
  65.      2.1 Rounds......................................................3
  66.      2.2 Background on RC5...........................................3
  67.      2.3 Performance.................................................3
  68.    3. Key Sizes......................................................3
  69.      3.1 Weak Keys...................................................3
  70.    4. ESP Payload....................................................3
  71.      4.1 Block Size and Padding......................................4
  72.      4.2 Interaction with Authentication Algorithms..................4
  73.    5. Keying Material................................................4
  74.    6. Security Considerations........................................4
  75.    7. References.....................................................5
  76.    8. Acknowledgments................................................5
  77.    9. Editors' Addresses.............................................5
  78.  
  79. 1.  Introduction
  80.  
  81.    This document describes how the RC5 cipher algorithm may be used
  82.    with the IPSec ESP protocol.
  83.  
  84.    It is assumed that the reader is familiar with the terms and
  85.    concepts described in the document "Security Architecture for the
  86.    Internet Protocol" [Atkinson95] and "IP Encapsulating Security
  87.    Payload (ESP)" [Kent97].
  88.  
  89.    Furthermore, this document is a companion to [Kent97] and MUST be
  90.    read in its context.
  91.  
  92. 1.1 Specification of Requirements
  93.  
  94.    The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
  95.    NOT", and "MAY" that appear in this document are to be interpreted
  96.    as described in [Bradner97].
  97.  
  98. 2.  Cipher Algorithm
  99.  
  100.    The symmetric block cipher algorithm used to secure ESP is RC5 in
  101.    CBC mode with 16 rounds and a block size of 64 bits as described in
  102.    [Baldwin96].
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. R. Pereira, R. Baldwin                                        [Page 2]
  110.  
  111. Internet Draft        The ESP RC5-CBC Algorithm           July 2, 1997
  112.  
  113.  
  114. 2.1 Rounds
  115.  
  116.    RSA Labs recommends that RC5 be used with 16 rounds.  Twelve rounds
  117.    is enough to make RC5 stronger than DES against differential and
  118.    linear cryptanalysis and sixteen rounds is sufficient to make RC5
  119.    secure against both forms of cryptanalysis even at a theoretical
  120.    level.
  121.  
  122.    Compliant implementations MUST support 16 rounds.
  123.  
  124. 2.2 Background on RC5
  125.  
  126.    The RC5 encryption algorithm was developed by Ron Rivest for RSA
  127.    Data Security Inc. in order to address the need for a high-
  128.    performance software and hardware ciphering alternative to DES.
  129.  
  130. 2.3 Performance
  131.  
  132.    Benchmark numbers from RSA Data Security suggest that RC5-CBC runs
  133.    about twice as fast as Eric Young's DES-CBC implementation from
  134.    SSLeay on the popular 32-bit CPUs.
  135.  
  136. 3.  Key Sizes
  137.  
  138.    RC5's key size MUST be multiple of 8 bits and MUST be from 40 to
  139.    2040 bits  inclusive. To facilitate interoperability, it is
  140.    recommended that key sizes SHOULD be chosen from the set of 40, 128
  141.    and 160 bits.
  142.  
  143.    If the key size is not negotiated through the key exchange
  144.    protocol, then a value of 128 bits MUST be used.  All compliant
  145.    implementations MUST support a key size of 128 bits.
  146.  
  147. 3.1 Weak Keys
  148.  
  149.    RC5 has no known weak keys when used with 16 rounds.
  150.  
  151. 4.  ESP Payload
  152.  
  153.    RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets
  154.    (64 bits) that immediately precedes the cipher-text in the payload.
  155.    The IV SHOULD be chosen at random.  Common practice is to use
  156.    random data for the first IV and the last 8 octets of encrypted
  157.    data from an encryption process as the IV for the next encryption
  158.    process.
  159.  
  160.  
  161.  
  162.  
  163. R. Pereira, R. Baldwin                                        [Page 3]
  164.  
  165. Internet Draft        The ESP RC5-CBC Algorithm           July 2, 1997
  166.  
  167.  
  168.    The payload field, as defined in [Kent97], is broken down according
  169.    to the following diagram:
  170.  
  171.    +---------------+---------------+---------------+---------------+
  172.    |                                                               |
  173.    +                   Initialization Vector (IV)                  +
  174.    |                                                               |
  175.    +---------------+---------------+---------------+---------------+
  176.    |                                                               |
  177.    ~              Encrypted Payload (variable length)              ~
  178.    |                                                               |
  179.    +---------------------------------------------------------------+
  180.     1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
  181.  
  182. 4.1 Block Size and Padding
  183.  
  184.    RC5 has a variably length block size, but for the ESP algorithm
  185.    described in this document, the block size MUST be 8 octets (64
  186.    bits).
  187.  
  188.    When padding is required, it MUST be done according to the
  189.    conventions specified in [Kent97].
  190.  
  191. 4.2 Interaction with Authentication Algorithms
  192.  
  193.    This ESP RC5 document has no limitations on what authentication
  194.    algorithm is used in ESP.
  195.  
  196. 5.  Keying Material
  197.  
  198.    The minimum number of bits sent from the Key Exchange Protocol to
  199.    this ESP algorithm must be greater or equal to the key size.
  200.  
  201.    The RC5 key is taken from the first <x> bits of the keying
  202.    material.  Where <x> represents the required key size.
  203.  
  204. 6.  Security Considerations
  205.  
  206.    The ESP RC5 algorithm described in this document has the same
  207.    security considerations as in [Baldwin96].
  208.  
  209.    Care should be taken when using small key sizes.  Small key sizes
  210.    make brute force type attacks practical regardless of the cipher
  211.    algorithm used.  It is therefore recommended that the ESP RC5 key
  212.    size be at least 80 bits.  Use of key sizes less than 80 bits is
  213.    permitted, but careful considerations should be taken before its
  214.    use.
  215.  
  216.  
  217. R. Pereira, R. Baldwin                                        [Page 4]
  218.  
  219. Internet Draft        The ESP RC5-CBC Algorithm           July 2, 1997
  220.  
  221.  
  222. 7.  References
  223.  
  224.    [Atkinson95] Atkinson, R., "Security Architecture for the Internet
  225.    Protocol", draft-ietf-ipsec-arch-sec-01
  226.  
  227.    [Baldwin96] Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC-
  228.    Pad, and RC5-CTS Algorithms", RFC2040, October 1996
  229.  
  230.    [Bradner97] Bradner, S., "Key words for use in RFCs to indicate
  231.    Requirement Levels", RFC2119, March 1997
  232.  
  233.    [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
  234.    (ESP)", draft-ietf-ipsec-new-esp-01
  235.  
  236. 8.  Acknowledgments
  237.  
  238.    This document is based on previous work by B. Howard of TimeStep
  239.    Corporation, suggestions from Stephen Kent, discussions from the
  240.    IPSec mailing list as well as the other IPSec drafts.
  241.  
  242. 9.  Editors' Addresses
  243.  
  244.  
  245.      Roy Pereira
  246.      <rpereira@timestep.com>
  247.      TimeStep Corporation
  248.      (613) 599-3610 x 4808
  249.  
  250.      Robert W. Baldwin
  251.      <baldwin@rsa.com> or <baldwin@lcs.mit.edu>
  252.      RSA Data Security, Inc.
  253.      (415)
  254.            595-8782
  255.  
  256.    The IPSec working group can be contacted via the IPSec working
  257.    group's mailing list (ipsec@tis.com) or through its chairs:
  258.  
  259.      Robert Moskowitz
  260.      rgm@chrysler.com
  261.      Chrysler Corporation
  262.  
  263.      Theodore Y. Ts'o
  264.      tytso@MIT.EDU
  265.      Massachusetts Institute of Technology
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272. R. Pereira, R. Baldwin                                        [Page 5]
  273.  
  274.  
  275.