HMAC-MD5 IP Authentication with Replay Prevention
RFC 2085

Document Type RFC - Proposed Standard (February 1997; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2085 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         M. Oehler
Request for Comments: 2085                                          NSA
Category: Standards Track                                      R. Glenn
                                                                   NIST
                                                          February 1997

           HMAC-MD5 IP Authentication with Replay Prevention

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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.

Table of Contents

   1.  Introduction...................................................1
   1.1    Terminology.................................................2
   1.2    Keys........................................................2
   1.3    Data Size...................................................3
   2.  Packet Format..................................................3
   2.1    Replay Prevention...........................................4
   2.2    Authentication Data Calculation.............................4
   3.  Security Considerations........................................5
   Acknowledgments....................................................5
   References.........................................................6
   Authors' Addresses.................................................6

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
   digest. 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.

Oehler & Glenn              Standards Track                     [Page 1]
RFC 2085                        HMAC-MD5                  February 1997

   To provide protection against replay attacks, a Replay Prevention
   field is included as a transform option.  This field is used to help
   prevent attacks in which a message is stored and re-used later,
   replacing or repeating the original.  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].

   All implementations that claim conformance or compliance with the IP
   Authentication Header specification [RFC-1826] MUST implement this
   HMAC-MD5 transform.

1.1 Terminology

   In  this  document,  the  words  that  are  used  to   define   the
   significance  of each particular requirement are usually capitalized.
   These words are:

   - MUST

   This word or the adjective "REQUIRED" means that  the  item  is  an
   absolute requirement of the specification.

   - SHOULD

   This word or the adjective "RECOMMENDED"  means  that  there  might
   exist  valid reasons in particular circumstances to ignore this item,
   but the full implications should be understood and the case carefully
   weighed before taking a different course.

1.2 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

Oehler & Glenn              Standards Track                     [Page 2]
RFC 2085                        HMAC-MD5                  February 1997

   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]
Show full document text