IP Authentication Header (RFC1826)
Original Publication Date: 1995-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
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.
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.
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.
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-
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].
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",
"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...