IP Authentication Header
RFC 1826

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                        R. Atkinson
Request for Comments: 1826                     Naval Research Laboratory
Category: Standards Track                                    August 1995

                        IP Authentication Header

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 mechanism for providing cryptographic
   authentication for IPv4 and IPv6 datagrams.  An Authentication Header
   (AH) is normally inserted after an IP header and before the other
   information being authenticated.

1. INTRODUCTION

   The Authentication Header is a mechanism for providing strong
   integrity and authentication for IP datagrams.  It might also provide
   non-repudiation, depending on which cryptographic algorithm is used
   and how keying is performed.  For example, use of an asymmetric
   digital signature algorithm, such as RSA, could provide non-
   repudiation.

   Confidentiality, and protection from traffic analysis are not
   provided by the Authentication Header.  Users desiring
   confidentiality should consider using the IP Encapsulating Security
   Protocol (ESP) either in lieu of or in conjunction with the
   Authentication Header [Atk95b].  This document assumes the reader has
   previously read the related IP Security Architecture document which
   defines the overall security architecture for IP and provides
   important background information for this specification [Atk95a].

1.1 Overview

   The IP Authentication Header seeks to provide security by adding
   authentication information to an IP datagram. This authentication
   information is calculated using all of the fields in the IP datagram
   (including not only the IP Header but also other headers and the user
   data) which do not change in transit.  Fields or options which need
   to change in transit (e.g., "hop count", "time to live", "ident",

Atkinson                    Standards Track                     [Page 1]
RFC 1826                IP Authentication Header             August 1995

   "fragment offset", or "routing pointer") are considered to be zero
   for the calculation of the authentication data.  This provides
   significantly more security than is currently present in IPv4 and
   might be sufficient for the needs of many users.

   Use of this specification will increase the IP protocol processing
   costs in participating end systems and will also increase the
   communications latency.  The increased latency is primarily due to
   the calculation of the authentication data by the sender and the
   calculation and comparison of the authentication data by the receiver
   for each IP datagram containing an Authentication Header.  The impact
   will vary with authentication algorithm used and other factors.

   In order for the Authentication Header to work properly without
   changing the entire Internet infrastructure, the authentication data
   is carried in its own payload.  Systems that aren't participating in
   the authentication MAY ignore the Authentication Data.  When used
   with IPv6, the Authentication Header is normally placed after the
   Fragmentation and End-to-End headers and before the ESP and
   transport-layer headers.  The information in the other IP headers is
   used to route the datagram from origin to destination.  When used
   with IPv4, the Authentication Header immediately follows an IPv4
   header.

   If a symmetric authentication algorithm is used and intermediate
   authentication is desired, then the nodes performing such
   intermediate authentication would need to be provided with the
   appropriate keys.  Possession of those keys would permit any one of
   those systems to forge traffic claiming to be from the legitimate
   sender to the legitimate receiver or to modify the contents of
   otherwise legitimate traffic.  In some environments such intermediate
   authentication might be desirable [BCCH94].  If an asymmetric
   authentication algorithm is used and the routers are aware of the
   appropriate public keys and authentication algorithm, then the
   routers possessing the authentication public key could authenticate
   the traffic being handled without being able to forge or modify
   otherwise legitimate traffic.  Also, Path MTU Discovery MUST be used
   when intermediate authentication of the Authentication Header is
   desired and IPv4 is in use because with this method it is not
   possible to authenticate a fragment of a packet [MD90] [Kno93].

Atkinson                    Standards Track                     [Page 2]
RFC 1826                IP Authentication Header             August 1995