draft-ietf-ipsec-ah-hmac-md5-00.txt

Robert Glenn <glenn@snad.ncsl.nist.gov> Tue, 30 April 1996 18:43 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21737; 30 Apr 96 14:43 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21732; 30 Apr 96 14:43 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa07993; 30 Apr 96 14:43 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa00938; 30 Apr 96 14:16 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa00924; 30 Apr 96 14:12 EDT
Received: by relay.tis.com; id OAA28532; Tue, 30 Apr 1996 14:13:19 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028525; Tue, 30 Apr 96 14:12:53 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23933; Tue, 30 Apr 96 14:13:12 EDT
Received: by relay.tis.com; id OAA28521; Tue, 30 Apr 1996 14:12:49 -0400
Received: from snad.ncsl.nist.gov(129.6.55.1) by relay.tis.com via smap (V3.1) id xma028511; Tue, 30 Apr 96 14:12:21 -0400
Received: by snad.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA00644; Tue, 30 Apr 96 14:14:51 EDT
Date: Tue, 30 Apr 1996 14:14:51 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert Glenn <glenn@snad.ncsl.nist.gov>
Message-Id: <9604301814.AA00644@snad.ncsl.nist.gov>
To: internet-drafts@CNRI.Reston.VA.US, ipsec@tis.com
Subject: draft-ietf-ipsec-ah-hmac-md5-00.txt
X-Orig-Sender: ipsec-approval@neptune.tis.com
Precedence: bulk






Network Working Group                                   M. Oehler (NSA)
                                                        R. Glenn (NIST)
Internet Draft                                          May 1, 1996


           HMAC-MD5 IP Authentication with Replay Prevention
                 <draft-ietf-ipsec-ah-hmac-md5-00.txt>


Status of This Memo

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working 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
   reference 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)

Abstract

   This document describes a keyed-MD5 transform to be used in
   conjunction with the IP Authentication Header [RFC-1826]. The
   particular transform is based on [HMAC-MD5].  An option is also
   specified to guard against replay attacks.











Oehler, Glenn                                                   [Page 1]

INTERNET DRAFT                May 1, 1996          Expires November 1996


Contents

   1.  Introduction...................................................3
   1.1    Keys........................................................3
   1.2    Data Size...................................................4
   2.  Packet Format..................................................4
   2.1    Replay Prevention...........................................4
   2.2    Authentication Data Calculation.............................5
   3.  Security Considerations........................................6
   ACKNOWLEDGMENTS....................................................6
   REFERENCES.........................................................6
   CONTACTS...........................................................6







































Oehler, Glenn                                                   [Page 2]

INTERNET DRAFT                May 1, 1996          Expires November 1996


1. Introduction

   The Authentication Header (AH) [RFC-1826] provides integrity and
   authentication for IP datagrams. The transform specified in this
   document uses a keyed-MD5 mechanism [HMAC-MD5].  The mechanism uses
   the (key-less) MD5 hash function [RFC-1321] which produces a message
   authentication code. When combined with an AH Key, authentication
   data is produced. This value is placed in the Authentication Data
   field of the AH [RFC-1826]. This value is also the basis for the data
   integrity service offered by the AH protocol.

   To provide protection against replay attacks, a Replay Prevention
   field is included as a transform option.  The Security Parameters
   Index (SPI) [RFC-1825] is used to determine whether this option is
   included in the AH.

   Familiarity with the following documents is assumed: "Security
   Architecture for the Internet Protocol" [RFC-1825], "IP
   Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for
   Message Authentication" [HMAC-MD5].

1.1 Keys

   The "AH Key" is used as a shared secret between two communicating
   parties.  The Key is not a "cryptographic key" as used in a
   traditional sense. Instead, the AH key (shared secret) is hashed with
   the transmitted data and thus, assures that an intervening party
   cannot duplicate the authentication data.

   Even though an AH key is not a cryptographic key, the rudimentary
   concerns of cryptographic keys still apply. Consider that the
   algorithm and most of the data used to produce the output is known.
   The strength of the transform lies in the singular mapping of the key
   (which needs to be strong) and the IP datagram (which is known) to
   the authentication data.  Thus, implementations should, and as
   frequently as possible, change the AH key. Keys need to be chosen at
   random, or generated using a cryptographically strong pseudo-random
   generator seeded with a random seed. [HMAC-MD5]

   There is no mandated key size for the HMAC-MD5 transform.
   Implementations must support a key length of any size, except zero.
   It is advised that keys be chosen as the length of the hash output,
   or 128-bits for MD5. For other key lengths, the following concerns
   must be considered.

   A key length of zero is prohibited and implementations should provide
   an alert, since the authentication data would be identical to that of
   MD5, solely.  Less than 16 bytes is strongly discouraged as it would



Oehler, Glenn                                                   [Page 3]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   decrease the security strength of the function.  Keys longer than 16
   bytes are acceptable, but the extra length would not significantly
   increase the function strength. A longer key may be advisable if the
   randomness of the key is suspect.  MD5 operates on 64-byte blocks.
   Keys longer than 64 bytes are first hashed using MD5.  The resulting
   hash is then used to calculate the authentication data.

1.2 Data Size

   MD5 produces a 128-bit value which is used as the authentication
   data.  It is naturally 64 bit aligned and thus, does not need any
   padding for machines with native double words.

2. Packet Format

        +---------------+---------------+---------------+---------------+
        | Next Header   | Length        |           RESERVED            |
        +---------------+---------------+---------------+---------------+
        |                              SPI                              |
        +---------------+---------------+---------------+---------------+
        +                     Replay Prevention  (optional)             |
        +---------------+---------------+---------------+---------------+
        |                                                               |
        +                     Authentication Data                       |
        |                                                               |
        +---------------+---------------+---------------+---------------+
         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

   The Next Header, RESERVED, and SPI fields are specified in [RFC-
   1826].  The Length field is the length of the Replay Prevention field
   and the Authentication Data in 32-bit words.

2.1 Replay Prevention

   The Replay Prevention field is a 32 bit value used to guarantee that
   each packet exchanged between two parties is different.  This field
   is similar to the one specified in [ESP-DES-MD5].  The SPI is used to
   determine whether or not the field is included in the packet (i.e. if
   it is not included, the header will have the SPI directly followed by
   the Authentication Data).  Without this field it is possible to
   attack a system by retransmitting packets.

   The 32-bit field is an up counter starting at a value of 1.

   The secret shared key must not be used for a period of time that
   allows the counter to wrap, that is, to transmit more than 2^32
   packets using a single key.




Oehler, Glenn                                                   [Page 4]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   Upon receipt, the replay value is assured to be increasing.  The
   implementation may accept of out of order packets. The number of
   packets to accept out of order is an implementation detail. If a "out
   of order window" is supported, the implementation shall ensure that
   any and all packets accepted out of order are guaranteed not to have
   arrived before. That is, the implementation will accept any packet at
   most once.

   [ESP-DES-MD5] provides example code that implements a 32 packet
   replay window and a test routine to show how it works.

2.2 Authentication Data Calculation

   The authentication data is the output of the authentication algorithm
   (MD5).  This value is calculated over the entire IP datagram. Fields
   within the datagram that are variant during transit and the
   authentication data field itself, must contain all zeros [RFC-1826].
   The Replay Prevention field if present, is included in the
   calculation.

   The definition and reference implementation of MD5 appears in [RFC-
   1321].  Let 'text' denote the data to which HMAC-MD5 is to be applied
   and K be the message authentication secret key shared by the parties.

   We define two fixed and different strings ipad and opad as follows
   (the 'i' and 'o' are mnemonics for inner and outer):
                  ipad = the byte 0x36 repeated 64 times
                  opad = the byte 0x5C repeated 64 times.
   To compute HMAC-MD5 over the data `text' we perform
                         MD5(K XOR opad, MD5(K XOR ipad, text))
   Namely,
          (1) append zeros to the end of K to create a 64 byte string
              (e.g., if K is of length 16 bytes it will be appended with 48
              zero bytes 0x00)
          (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step
              (1) with ipad
          (3) append the data stream 'text' to the 64 byte string resulting
              from step (2)
          (4) apply MD5 to the stream generated in step (3)
          (5) XOR (bitwise exclusive-OR) the 64 byte string computed in
              step (1) with opad
          (6) append the MD5 result from step (4) to the 64 byte string
              resulting from step (5)
          (7) apply MD5 to the stream generated in step (6) and output
              the result

      This computation is described in more detail, along with example
      code and performance improvements, in [HMAC-MD5].



Oehler, Glenn                                                   [Page 5]

INTERNET DRAFT                May 1, 1996          Expires November 1996


3. Security Considerations

   The security of this transform depends heavily on the strength of MD5
   and the associated secret key.  [HMAC-MD5] contains a detailed
   discussion on the strengths and weaknesses of MD5.

Acknowledgments

   This document is largely based on text written by Hugo Krawczyk.  The
   format used was derived from work by William Simpson and Perry
   Metzger.  The text on replay prevention is derived directly from work
   by Jim Hughes.

References


   [RFC-1825]    R. Atkinson, "Security Architecture for the Internet
                 Protocol", RFC-1852, Naval Research Laboratory, July 1995.
   [RFC-1826]    R. Atkinson, "IP Authentication Header",
                 RFC-1826, August 1995.
   [RFC-1828]    P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5",
                 RFC-1828, August 1995.
   [RFC-1321]    R. Rivest, "The MD5 Message-Digest Algorithm",
                 RFC-1321, April 1992.
   [HMAC-MD5]    H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5
                 for Message Authentication", Internet Draft, March, 1996.
   [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention
                 Security Transform", Internet Draft, April, 1996.


Contacts

   Michael J. Oehler
   National Security Agency
   Atn: R23, INFOSEC Research and Development
   9800 Savage Road
   Fort Meade, MD 20755

   mjo@tycho.ncsc.mil

   Robert Glenn
   NIST
   Building 820, Room 455
   Gaithersburg, MD 20899

   rob.glenn@nist.gov





Oehler, Glenn                                                   [Page 6]