IP Authentication Header
RFC 1826
| Document | Type |
RFC - Proposed Standard
(August 1995; No errata)
Obsoleted by RFC 2402
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 1826 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
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].
Show full document text