home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1852 < prev    next >
Text File  |  1995-10-02  |  9KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         P. Metzger
  8. Request for Comments: 1852                                      Piermont
  9. Category: Experimental                                        W. Simpson
  10.                                                               Daydreamer
  11.                                                           September 1995
  12.  
  13.  
  14.                    IP Authentication using Keyed SHA
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.  
  20.    This document defines an Experimental Protocol for the Internet
  21.    community.  This does not specify an Internet standard of any kind.
  22.    Discussion and suggestions for improvement are requested.
  23.    Distribution of this memo is unlimited.
  24.  
  25.  
  26. Abstract
  27.  
  28.    This document describes the use of keyed SHA with the IP
  29.    Authentication Header.
  30.  
  31.  
  32. Table of Contents
  33.  
  34.      1.     Introduction ..........................................    2
  35.         1.1       Keys ............................................    2
  36.         1.2       Data Size .......................................    2
  37.         1.3       Performance .....................................    2
  38.  
  39.      2.     Calculation ...........................................    3
  40.  
  41.      SECURITY CONSIDERATIONS ......................................    4
  42.      ACKNOWLEDGEMENTS .............................................    4
  43.      REFERENCES ...................................................    5
  44.      AUTHOR'S ADDRESS .............................................    6
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Metzger & Simpson             Experimental                      [Page 1]
  59.  
  60. RFC 1852                         AH SHA                   September 1995
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    The Authentication Header (AH) [RFC-1826] provides integrity and
  66.    authentication for IP datagrams.  This specification describes the AH
  67.    use of keys with the Secure Hash Algorithm (SHA) [FIPS-180-1].
  68.  
  69.       It should be noted that this document specifies a newer version of
  70.       the SHA than that described in [FIPS-180], which was flawed.  The
  71.       older version is not interoperable with the newer version.
  72.  
  73.    This document assumes that the reader is familiar with the related
  74.    document "Security Architecture for the Internet Protocol" [RFC-
  75.    1825], which defines the overall security plan for IP, and provides
  76.    important background for this specification.
  77.  
  78.  
  79.  
  80. 1.1.  Keys
  81.  
  82.    The secret authentication key shared between the communicating
  83.    parties SHOULD be a cryptographically strong random number, not a
  84.    guessable string of any sort.
  85.  
  86.    The shared key is not constrained by this transform to any particular
  87.    size.  Lengths of up to 160 bits MUST be supported by the
  88.    implementation, although any particular key may be shorter.  Longer
  89.    keys are encouraged.
  90.  
  91.  
  92.  
  93. 1.2.  Data Size
  94.  
  95.    SHA's 160-bit output is naturally 32-bit aligned.  However, many
  96.    implementations require 64-bit alignment of the following headers, in
  97.    which case an additional 32 bits of padding is added, either before
  98.    or after the SHA output.
  99.  
  100.    The size and position of this padding are negotiated as part of the
  101.    key management.  Padding bits are filled with unspecified
  102.    implementation dependent (random) values, which are ignored on
  103.    receipt.
  104.  
  105.  
  106.  
  107. 1.3.  Performance
  108.  
  109.    Preliminary results indicate that SHA is 62% as fast as MD5, and 80%
  110.    as fast as DES hashing.  That is,
  111.  
  112.  
  113.  
  114. Metzger & Simpson             Experimental                      [Page 2]
  115.  
  116. RFC 1852                         AH SHA                   September 1995
  117.  
  118.  
  119.                            SHA < DES < MD5
  120.  
  121.    Nota Bene:
  122.       Suggestions are sought on alternative authentication algorithms
  123.       that have significantly faster throughput, are not patent-
  124.       encumbered, and still retain adequate cryptographic strength.
  125.  
  126.  
  127.  
  128. 2.  Calculation
  129.  
  130.    The 160-bit digest is calculated as described in [FIPS-180-1].  At
  131.    the time of writing, a portable C language implementation of SHA is
  132.    available via FTP from ftp://rand.org/pub/jim/sha.tar.gz.
  133.  
  134.    The form of the authenticated message is
  135.  
  136.             key, keyfill, datagram, key, SHAfill
  137.  
  138.    First, the variable length secret authentication key is filled to the
  139.    next 512-bit boundary, using the same pad with length technique
  140.    defined for SHA.
  141.  
  142.    Then, the filled key is concatenated with (immediately followed by)
  143.    the invariant fields of the entire IP datagram (variant fields are
  144.    zeroed), concatenated with (immediately followed by) the original
  145.    variable length key again.
  146.  
  147.    A trailing pad with length to the next 512-bit boundary for the
  148.    entire message is added by SHA itself.  The 128-bit SHA digest is
  149.    calculated, and the result is inserted into the Authentication Data
  150.    field.
  151.  
  152.    Discussion:
  153.       The leading copy of the key is padded in order to facilitate
  154.       copying of the key at machine boundaries without requiring re-
  155.       alignment of the following datagram.  The padding technique
  156.       includes a length which protects arbitrary length keys.  Filling
  157.       to the SHA block size also allows the key to be prehashed to avoid
  158.       the physical copy in some implementations.
  159.  
  160.       The trailing copy of the key is not necessary to protect against
  161.       appending attacks, as the IP datagram already includes a total
  162.       length field.  It reintroduces mixing of the entire key, providing
  163.       minimal protection for very long and very short datagrams, and
  164.       marginal robustness against possible attacks on the IP length
  165.       field itself.
  166.  
  167.  
  168.  
  169.  
  170. Metzger & Simpson             Experimental                      [Page 3]
  171.  
  172. RFC 1852                         AH SHA                   September 1995
  173.  
  174.  
  175.       When the implementation adds the keys and padding in place before
  176.       and after the IP datagram, care must be taken that the keys and/or
  177.       padding are not sent over the link by the link driver.
  178.  
  179.  
  180.  
  181. Security Considerations
  182.  
  183.    Users need to understand that the quality of the security provided by
  184.    this specification depends completely on the strength of the SHA hash
  185.    function, the correctness of that algorithm's implementation, the
  186.    security of the key management mechanism and its implementation, the
  187.    strength of the key [CN94], and upon the correctness of the
  188.    implementations in all of the participating nodes.
  189.  
  190.    The SHA algorithm was originally derived from the MD4 algorithm
  191.    [RFC-1320].  A flaw was apparently found in the original
  192.    specification of SHA [FIPS-180], and this document specifies the use
  193.    of a corrected version [FIPS-180-1].
  194.  
  195.    At the time of writing of this document, there are no known flaws in
  196.    the SHA algorithm.  That is, there are no known attacks on SHA or any
  197.    of its components that are better than brute force, and the 160-bit
  198.    hash output by SHA is substantially more resistant to brute force
  199.    attacks than the 128-bit hash size of MD4 and MD5.
  200.  
  201.    However, as the flaw in the original SHA algorithm shows,
  202.    cryptographers are fallible, and there may be substantial
  203.    deficiencies yet to be discovered in the algorithm.
  204.  
  205.  
  206.  
  207. Acknowledgements
  208.  
  209.    Some of the text of this specification was derived from work by
  210.    Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.
  211.  
  212.    Preliminary performance analysis was provided by Joe Touch.
  213.  
  214.    Comments should be submitted to the ipsec@ans.net mailing list.
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Metzger & Simpson             Experimental                      [Page 4]
  227.  
  228. RFC 1852                         AH SHA                   September 1995
  229.  
  230.  
  231. References
  232.  
  233.    [CN94]   John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data:
  234.             Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
  235.             253-280, July 1994.
  236.  
  237.    [FIPS-180]
  238.             "Secure Hash Standard", Computer Systems Laboratory,
  239.             National Institute of Standards and Technology, U.S.
  240.             Department Of Commerce, May 1993.
  241.  
  242.             Also known as: 58 Fed Reg 27712 (1993).
  243.  
  244.    [FIPS-180-1]
  245.             "Secure Hash Standard", National Institute of Standards and
  246.             Technology, U.S. Department Of Commerce, April 1995.
  247.  
  248.             Also known as: 59 Fed Reg 35317 (1994).
  249.  
  250.    [RFC-1320]
  251.             Ronald Rivest, "The MD4 Message-Digest Algorithm", RFC-1320,
  252.             April 1992.
  253.  
  254.    [RFC-1700]
  255.             Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
  256.             1700, USC/Information Sciences Institute, October 1994.
  257.  
  258.    [RFC-1825]
  259.             Atkinson, R., "Security Architecture for the Internet
  260.             Protocol", RFC-1825, Naval Research Laboratory, July 1995.
  261.  
  262.    [RFC-1826]
  263.             Atkinson, R., "IP Authentication Header", RFC-1826, Naval
  264.             Research Laboratory, July 1995.
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Metzger & Simpson             Experimental                      [Page 5]
  283.  
  284. RFC 1852                         AH SHA                   September 1995
  285.  
  286.  
  287. Author's Address
  288.  
  289.    Questions about this memo can also be directed to:
  290.  
  291.       Perry Metzger
  292.       Piermont Information Systems Inc.
  293.       160 Cabrini Blvd., Suite #2
  294.       New York, NY  10033
  295.  
  296.       perry@piermont.com
  297.  
  298.  
  299.       William Allen Simpson
  300.       Daydreamer
  301.       Computer Systems Consulting Services
  302.       1384 Fontaine
  303.       Madison Heights, Michigan  48071
  304.  
  305.       Bill.Simpson@um.cc.umich.edu
  306.           bsimpson@MorningStar.com
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Metzger & Simpson             Experimental                      [Page 6]
  339.  
  340.