[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 rfc2841                                            Historic
Network Working Group                                          P Metzger
Internet Draft                                                  Piermont
                                                             W A Simpson
expires in six months                                         April 1996

          IP Authentication using Keyed SHA1 with Data Padding

Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.


   This document describes the use of keyed SHA1 with the IP Authentica-
   tion Header.

Metzger & Simpson         expires in six months                 [Page i]

DRAFT                            AH SHA                       April 1996

1.  Introduction

   The Authentication Header (AH) [RFC-1826] provides integrity and
   authentication for IP datagrams.  This specification describes the AH
   use of keys with the Secure Hash Algorithm (SHA1) [FIPS-180-1].  This
   SHA1-KDP algorithm uses a leading and trailing key (a variant of the
   "envelope method"), with alignment padding between both keys and

      It should be noted that this document specifies a newer version of
      the SHA than that described in [FIPS-180], which was flawed.  The
      older version is not interoperable with the newer version.

   This document assumes that the reader is familiar with the related
   document "Security Architecture for the Internet Protocol"
   [RFC-1825], that defines the overall security plan for IP, and pro-
   vides important background for this specification.

1.1.  Keys

   The secret authentication key shared between the communicating par-
   ties SHOULD be a cryptographically strong random number, not a guess-
   able string of any sort.

   The shared key is not constrained by this transform to any particular
   size.  Lengths of 160-bits (20 octets) MUST be supported by the
   implementation, although any particular key may be shorter.  Longer
   keys are encouraged.

1.2.  Data Size

   SHA1's 160-bit output is naturally 32-bit aligned.  However, many
   implementations require 64-bit alignment of the following headers.

   Therefore, several options are available for data alignment (most
   preferred to least preferred):

   1) only the most significant 128-bits (16 octets) of output are used.

   2) an additional 32-bits (4 octets) of padding is added before the
      SHA1 output.

   3) an additional 32-bits (4 octets) of padding is added after the
      SHA1 output.

Metzger & Simpson         expires in six months                 [Page 1]

DRAFT                            AH SHA                       April 1996

   4) the SHA1 output is variably bit-positioned within 192-bits (24

   The size and position of the output are negotiated as part of the key
   management.  Padding bits are filled with unspecified implementation
   dependent (random) values, which are ignored on receipt.


      Although truncation of the output for alignment purposes may
      appear to reduce the effectiveness of the algorithm, some analysts
      of attack verification suggest that this may instead improve the
      overall robustness [PO95a].

1.3.  Performance

   Preliminary results indicate that SHA1 is 62% as fast as MD5, and 80%
   as fast as DES hashing.  That is:

                           SHA1 < DES < MD5

   This appears to be a reasonable performance tradeoff, as SHA1 inter-
   nal chaining is significantly longer than either DES or MD5:

                           DES < MD5 < SHA1

   Nota Bene:
      Suggestions are sought on alternative authentication algorithms
      that have significantly faster throughput, are not patent-
      encumbered, and still retain adequate cryptographic strength.

2.  Calculation

   The 160-bit digest is calculated as described in [FIPS-180-1].  A
   portable C language implementation of SHA1 is available via FTP from

   The form of the authenticated message is:

         SHA1( key, keyfill, datagram, datafill, key, sha1fill )

   First, the variable length secret authentication key is filled to the
   next 512-bit boundary, using the same pad-with-length technique
   defined for SHA1.  The padding technique includes a length that pro-
   tects arbitrary length keys.

Metzger & Simpson         expires in six months                 [Page 2]

DRAFT                            AH SHA                       April 1996

   Next, the filled key is concatenated with (immediately followed by)
   the invariant fields of the entire IP datagram (variant fields are
   zeroed).  This is also filled to the next 512-bit boundary, using the
   same pad-with-length technique defined for SHA1.  The length includes
   the leading key and data.

   Then, the filled data is concatenated with (immediately followed by)
   the original variable length key again.  A trailing pad-with-length
   to the next 512-bit boundary for the entire message is added by SHA1

   Finally, the 160-bit SHA1 digest is calculated, and the result is
   inserted into the Authentication Data field.


      The leading copy of the key is padded in order to facilitate copy-
      ing of the key at machine boundaries without requiring re-
      alignment of the following datagram.  Filling to the SHA1 block
      size also allows the key to be prehashed to avoid the physical
      copy in some implementations.

      The trailing copy of the key is not necessary to protect against
      appending attacks, as the IP datagram already includes a total
      length field.  It reintroduces mixing of the entire key, providing
      protection for very long and very short datagrams, and robustness
      against possible attacks on the IP length field itself.

      When the implementation adds the keys and padding in place before
      and after the IP datagram, care must be taken that the keys and/or
      padding are not sent over the link by the link driver.

A.  Changes

   Changes from RFC-1852:

   Use of SHA1 term (as always intended).

   Added shortened 128-bit output, and clarify output text.

   Added tradeoff text.

   Changed padding technique to comply with Crypto '95 recommendations.

   Updated references.

   Updated contacts.

Metzger & Simpson         expires in six months                 [Page 3]

DRAFT                            AH SHA                       April 1996

   Minor editorial changes.

Security Considerations

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of the SHA1
   hash function, the correctness of that algorithm's implementation,
   the security of the key management mechanism and its implementation,
   the strength of the key, and upon the correctness of the implementa-
   tions in all of the participating nodes.

   The SHA algorithm was originally derived from the MD4 algorithm
   [RFC-1320].  A flaw was apparently found in the original specifica-
   tion of SHA [FIPS-180], and this document specifies the use of a cor-
   rected version [FIPS-180-1].

   At the time of writing of this document, there are no known flaws in
   the SHA1 algorithm.  That is, there are no known attacks on SHA1 or
   any of its components that are better than brute force, and the
   160-bit hash size of SHA1 is substantially more resistant to brute
   force attacks than the 128-bit hash size of MD4 and MD5.

   However, as the flaw in the original SHA1 algorithm shows, cryptogra-
   phers are fallible, and there may be substantial deficiencies yet to
   be discovered in the algorithm.


   Some of the text of this specification was derived from work by Ran-
   dall Atkinson for the SIP, SIPP, and IPv6 Working Groups.

   Preliminary performance analysis was provided by Joe Touch.

   Padding the leading copy of the key to a hash block boundary for
   increased performance was originally suggested by William Allen Simp-

   Padding the leading copy of the key to a hash block boundary for
   increased security was suggested by [KR95].  Including the key length
   for increased security was suggested by David Wagner.

   Padding the datagram to a hash block boundary to avoid (an impracti-
   cal) key recovery attack was suggested by [PO95b].

Metzger & Simpson         expires in six months                 [Page 4]

DRAFT                            AH SHA                       April 1996


            "Secure Hash Standard", Computer Systems Laboratory,
            National Institute of Standards and Technology, U.S. Depart-
            ment Of Commerce, May 1993.

            Also known as: 58 Fed Reg 27712 (1993).

            "Secure Hash Standard", National Institute of Standards and
            Technology, U.S. Department Of Commerce, April 1995.

            Also known as: 59 Fed Reg 35317 (1994).

   [KR95]   Kaliski, B., and Robshaw, M., "Message authentication with
            MD5", CryptoBytes (RSA Labs Technical Newsletter), vol.1
            no.1, Spring 1995.

   [PO95a]  Preneel, B., and van Oorshot, P., "MDx-MAC and Building Fast
            MACs from Hash Functions", Advances in Cryptology -- Crypto
            '95 Proceedings, Santa Barbara, California, August 1995.

   [PO95b]  Preneel, B., and van Oorshot, P., "On the Security of Two
            MAC Algorithms", Presented at the Rump Session of Crypto
            '95, Santa Barbara, California, August 1995.

            Ronald Rivest, "The MD4 Message-Digest Algorithm", RFC-1320,
            April 1992.

            Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
            1700, USC/Information Sciences Institute, October 1994.

            Atkinson, R., "Security Architecture for the Internet Proto-
            col", RFC-1825, Naval Research Laboratory, July 1995.

            Atkinson, R., "IP Authentication Header", RFC-1826, Naval
            Research Laboratory, July 1995.


Metzger & Simpson         expires in six months                 [Page 5]

DRAFT                            AH SHA                       April 1996

   Comments about this document should be discussed on the ipsec-
   dev@terisa.com mailing list.

   Questions about this document can also be directed to:

      Perry Metzger
      Piermont Information Systems Inc.
      160 Cabrini Blvd., Suite #2
      New York, NY  10033


      William Allen Simpson
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@GreenDragon.com (preferred)

Metzger & Simpson         expires in six months                 [Page 6]