Network Working Group Randall Atkinson
Internet Draft Naval Research Laboratory
draft-ietf-ipsec-auth-01.txt 25 April 1995
IP Authentication Header
STATUS OF THIS MEMO
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 6 months.
Internet Drafts 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". Please check the I-D abstract listing contained
in each Internet Draft directory to learn the current status of this
or any other Internet Draft.
This particular Internet Draft is a product of the IETF's IPng and
IPsec Working Groups. It is intended that a future version of this
draft will be submitted for consideration as a standards-track
document. Distribution of this document is unlimited.
0. ABSTRACT
This document describes a mechanism for providing cryptographic
authentication for IPv4 and IPv6 datagrams. An Authentication Header
(AH) is normally inserted after the main 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, for example RSA, could provide
non-repudiation.
Confidentiality, and protection from traffic analysis are not
Atkinson [Page 1]
Internet Draft IP Authentication Header 25 April 1995
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
which need to change in transit (e.g "hop count" or "routing pointer")
are omitted from 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
Hop-by-Hop header, which is examined at each hop, and before the
End-to-End Header, which is never examined at an intermediate hop.
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 the main 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
Atkinson [Page 2]
Internet Draft IP Authentication Header 25 April 1995
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 it is not possible to authenticate a fragement of a
packet. [MD90] [Kno93]
1.2 Requirements Terminology
In this document, the words that are used to define the significance
of each particular requirement are usually capitalised. 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.
- MAY
This word or the adjective "OPTIONAL" means that this item is truly
optional. One vendor might choose to include the item because a
particular marketplace requires it or because it enhances the product,
for example; another vendor may omit the same item.
2. KEY MANAGEMENT
Key management is an important part of the IP security architecture.
However, it is not integrated with this specification because of a
long history in the public literature of subtle flaws in key
management algorithms and protocols. The IP Authentication Header
tries to decouple the key management mechanisms from the security
protocol mechanisms. The only coupling between the key management
protocol and the security protocol is with the Security Association
Identifier (SPI), which is described in more detail below. This
decoupling permits several different key management mechanisms to be
used. More importantly, it permits the key management protocol to be
changed or corrected without unduly impacting the security protocol
implementations.
The key management mechanism is used to negotiate a number of
Atkinson [Page 3]
Internet Draft IP Authentication Header 25 April 1995
parameters for each "Security Association", including not only the
keys but also other information (e.g. the authentication algorithm and
mode) used by the communicating parties. The key management mechanism
creates and maintains a logical table containing the several
parameters for each current security association. An implementation
of the IP Authentication Header will need to read that logical table
of security parameters to determine how to process each datagram
containing an Authentication Header (e.g. to determine which
algorithm/mode and key to use in authentication). The combination of
Destination Address and SPI value is used to identify the appropriate
Security Association and hence the security parameters in use.
The IP Security Architecture document describes key management in
detail. It includes specification of the key management requirements
for this protocol, and is incorporated here by reference. [Atk95a]
3. AUTHENTICATION HEADER
The Authentication Header (AH) may appear after any other headers
which are examined at each hop, and before any other headers which
are not examined at an intermediate hop. The IPv4 or IPv6 header
immediately preceding the Authentication Header will contain the value
51 in its Next Header (or Protocol) field. [STD-2]
Example high-level diagrams of IP datagrams with the Authentication
Header follow.
+-------------+--------------------+-------------+--------+----------------+
| IPv6 Header | Hop-by-Hop/Routing | Auth Header | Others | Upper Protocol |
+-------------+--------------------+-------------+--------+----------------+
IPv6 Example
When used with IPv6, the Authentication Header normally appears after
the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options.
+-------------+--------------+-------------------------------+
| IPv4 Header | Auth Header | Upper Protocol (e.g TCP, UDP) |
+-------------+--------------+-------------------------------+
IPv4 Example
When used with IPv4, the Authentication Header normally follows the
main IPv4 header.
3.1 Authentication Header Syntax
The authentication data is the output of the authentication
algorithm calculated over the the entire IP datagram as described in
Atkinson [Page 4]
Internet Draft IP Authentication Header 25 April 1995
more detail later in this document. The authentication calculation
must treat the Authentication Data field itself and all fields that
are normally modified in transit (e.g. TTL or Hop Limit) as if those
fields contained all zeros. All other Authentication Header fields
are included in the authentication calculation normally.
The IP Authentication Header has the following syntax:
+--------------+---------------+----------------+--------------+
| Next Header | Length | RESERVED |
+--------------+---------------+----------------+--------------+
| Security Parameters Index |
+--------------+---------------+----------------+--------------+
| Authentication Data (variable number of 32-bit words) |
+--------------+---------------+----------------+--------------+
| (more Authentication Data) |
+--------------+---------------+----------------+--------------+
3.2 Fields of the Authentication Header
NEXT HEADER
8 bits wide. Identifies the next payload after the Authentication
Payload. This values in this field are the set of IP Protocol Numbers
as defined in the most recent RFC from the Internet Assigned Numbers
Authority (IANA) describing "Assigned Numbers". [STD-2]
PAYLOAD LENGTH
8 bits wide. The length of the Authentication Data field in 32-bit
words. Minimum value is 0 words, which is only used in the degenerate
case of a "null" authentication algorithm.
RESERVED
Reserved for future use. MUST be set to all zeros when sent and
ignored upon receipt.
SECURITY PARAMETERS INDEX (SPI)
A 32-bit pseudo-random value identifying the security association
for this datagram. The Ssecurity Parameters Index value 0 is
reserved to indicate that "no security association exists".
The set of Security Parameters Index values in the range 1
through 255 are reserved to the Internet Assigned Numbers
Authority (IANA) for future use. A reserved SPI value will not
normally be assigned by IANA unless the use of that particular
assigned SPI value is openly specified in an RFC.
Atkinson [Page 5]
Internet Draft IP Authentication Header 25 April 1995
AUTHENTICATION DATA
This length of this field is variable, but is always an integral
number of 32-bit words.
Many implementations require padding to other alignments, such as
64-bits, in order to improve performance. All implementations MUST
support such padding, which is specified by the Destination on a per
SPI basis.
An implementation will normally use the combination of Destination
Address and SPI to locate the Security Association which specifies
the field's size and use. The field retains the same format
for all datagrams of any given SPI and Destination Address pair.
The Authentication Data fills the field beginning immediately after
the SPI field. If the field is longer than necessary to store the
actual authentication data, then the unused bit positions are filled
with unspecified, implementation-dependent values. Those unused
bit positions MUST be ignored upon receipt.
Refer to each Authentication Mechanism specification for more
information regarding the contents of this field.
3.3 Sensitivity Labeling
As is discussed in greater detail in the IP Security Architecture
document, IPv6 will normally use implicit Security Labels rather than
the explicit labels that are currently used with IPv4. [Ken91]
[Atk95a] In some situations, users MAY choose to carry explicit labels
(for example, IPSO labels as defined by RFC-1108 might be used with
IPv4) in addition to using the implicit labels provided by the
Authentication Header. Explicit label options could be defined for
use with IPv6 (e.g. using the IPv6 end-to-end options header or the
IPv6 hop-by-hop options header). Implementations MAY support explicit
labels in addition to implicit labels, but implementations are not
required to support explicit labels. If explicit labels are in use,
then the explicit label MUST be included in the authentication
calculation.
4. CALCULATION OF THE AUTHENTICATION DATA
The authentication data is usually calculated using a message digest
algorithm (for example, MD5) either encrypting that message digest or
keying the message digest directly. [Riv92] Only algorithms that are
believed to be cryptographically strong one-way functions should be
used with this header.
Atkinson [Page 6]
Internet Draft IP Authentication Header 25 April 1995
Because conventional checksums (e.g. CRC-16) are not
cryptographically strong and can be reverse-engineered, they MUST NOT
be used with the Authentication Header.
If a block-oriented authentication algorithm (e.g. MD5, MD4) is in
use and the IP packet is not an integral number of blocks, the
authentication data calculation is performed using zero bytes at the
end to pad the length out to an integral number of blocks. [Riv92]
These block padding bytes are not included in the actual IP datagram
and are not sent over the wire because adding padding at that point in
IP protocol processing would make implementation of the MTU related
calculations very difficult.
The appropriate Security Association is first selected. This
selection is based at least upon the sending userid and the
Destination Address. When host-oriented keying is in use, all sending
userids will share the same Security Association to a given
destination. When user-oriented keying is in use, then different
users or possibly even different applications of the same user might
use different Security Associations. The Security Association
selected will indicate which algorithm, algorithm mode, key, and other
properties apply to the outgoing packet.
Fields which NECESSARILY are modified during transit from the sender
to the receiver (e.g. TTL or Hop Count) are included in the
authentication data calculation but the value zero is substituted for
the actual value of such fields in the IP packet. This substitution
of zero is used instead of omitting those fields because it preserves
alignment throughout the authentication data calculation and thereby
can significantly improve performance.
The sender MUST compute the authentication over the packet as it
will appear at the receiver. This requirement is placed in order to
allow for future IP optional headers which the receiver might not
know about but the sender necessarily knows about if it is including
such options in the packet. The sender places the calculated message
digest algorithm output into the Authentication Data field within the
Authentication Header.
Upon receipt of a packet containing an IP Authentication Header, the
receiver first uses the Destination Address and SPI value to locate
the correct Security Association. The receiver then independently
calculates the authentication data for the received packet. It then
compares the received Authentication Data field contents with the
calculated authentication value. If the two match, then the datagram
is accepted as authentic. If they differ, then the receiver SHOULD
discard the received IP datagram as non-authentic and MUST record the
authentication failure in the system log or audit log. If such a
Atkinson [Page 7]
Internet Draft IP Authentication Header 25 April 1995
failure occurs, the recorded log data MUST include the SPI value,
date/time received, clear-text Sending Address, clear-text Destination
Address, and clear-text Flow ID. The log data MAY also include other
information about the failed packet.
Not all of the fields of the IPv6 Hop-by-Hop Options header are
included in the authentication calculation. The third-highest-order
bit of the Option Type field within the IPv6 Hop-by-Hop Options Header
indicates whether any particular option is included within the
authentication calculation or is omitted from the authentication
calculation. If the particular option is to be omitted, that option
is skipped over during the authentication calculation as if it were
not present. Because of this bit encoding, an implementation can
authenticate newly defined IPv6 hop-by-hop options without having to
modify the authentication portion of the IP implementation. The IPv6
specification provides additional information on the IPv6 Hop-by-Hop
Options Header. [Hin94]
5. CONFORMANCE REQUIREMENTS
Implementations that claim conformance or compliance with this
specification MUST fully implement the header described here, MUST
support manual key distribution for use with this option, MUST comply
with all requirements of the "Security Architecuture for the Internet
Protocol" [Atk95a], and MUST support the use of keyed MD5 as described
in the companion document entitled "IP Authentication using Keyed MD5"
[MS95]. Implementations MAY also implement other authentication
algorithms. Implementors should consult the most recent version of
the "IAB Official Standards" RFC for further guidance on the status of
this document.
6. SECURITY CONSIDERATIONS
This entire RFC discusses an authentication mechanism for IP.
This mechanism is not a panacea to the several security issues in any
internetwork, however it does provide a component useful in building a
secure internetwork.
Users need to understand that the quality of the security provided
by this specification depends completely on the strength of whichever
cryptographic algorithm has been implemented, the strength of the key
being used, the correctness of that algorithm's implementation, upon
the security of the key management mechanism and its implementation,
and upon the correctness of the IP Authentication Header and IP
implementations in all of the participating systems. If any of these
assumptions do not hold, then little or no real security will be
provided to the user. Implementers are encouraged to use high
assurance methods to develop all of the security relevant parts of
their products.
Atkinson [Page 8]
Internet Draft IP Authentication Header 25 April 1995
Users interested in confidentiality should consider using the IP
Encapsulating Security Payload (ESP) instead of or in conjunction with
this specification. [Atk95b] Users seeking protection from traffic
analysis might consider the use of appropriate link encryption.
Description and specification of link encryption is outside the scope
of this note. [VK83] Users interested in combining the IP
Authentication Header with the IP Encapsulating Security Payload
should consult the IP Encapsulating Security Payload specification
for details.
One particular issue is that in some cases a packet which causes an
error to be reported back via ICMP might be so large as not to
entirely fit within the ICMP message returned. In such cases, it
might not be possible for the receiver of the ICMP message to
independently authenticate the portion of the returned message. This
could mean that the host receiving such an ICMP message would either
trust an unauthenticated ICMP message, which might in turn create some
security problem, or not trust and hence not react appropriately to
some legitimate ICMP message that should have been reacted to. It
is not clear that this issue can be fully resolved in the presence of
packets that are the same size as or larger than the minimum IP MTU.
Similar complications arise if an encrypted packet causes an ICMP
error message to be sent and that packet is truncated.
Active attacks are now widely known to exist in the Internet
[CER95]. The presence of active attacks means that unauthenticated
source routing, either unidirectional (receive-only) or with replies
following the original received source route represents a significant
security risk unless all received source routed packets are
authenticated using the IP Authentication Header or some other
cryptologic mechanism. It is noteworthy that the attacks described in
[CER95] include a subset of those described in [Bel89].
This documented benefited greatly from work done by Bill Simpson, Perry
Metzger, and Phil Karn to make general the approach originally defined
by the author for SIP, SIPP, and finally IPv6.
The basic concept here is derived in large part from the SNMPv2
Security Protocol work described in [GM93]. Steve Bellovin, Steve
Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided
thoughtful critiques of early versions of this note. Francis Dupont
discovered and pointed out the security issue with ICMP in low IP MTU
links that is noted just above.
REFERENCES
[Atk95a] Randall Atkinson, Security Architecture for the Internet Protocol,
draft-ietf-ipsec-arch-sec-01.txt, 25 April 1995.
Atkinson [Page 9]
Internet Draft IP Authentication Header 25 April 1995
[Atk95b] Randall Atkinson, IP Encapsulating Security Payload,
draft-ietf-ipsec-esp-01.txt, 25 April 1995.
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
ACM Computer Communications Review, Vol. 19, No. 2, March 1989.
[BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop
on Security in the Internet Architecture", RFC-1636, DDN Network
Information Center, 9 June 1994, pp. 21-34.
[CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and
Hijacked Terminal Connections", CA-95:01, January 1995.
Available via anonymous ftp from info.cert.org in /pub/cert_advisories.
[GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2), RFC-1446,
DDN Network Information Center, April 1993.
[Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification,
draft-hinden-ipv6-spec-00.txt, October 1994.
[Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol",
RFC-1108, DDN Network Information Center, November 1991.
[Kno93] Steve Knowles, "IESG Advice from Experience with Path MTU Discovery",
RFC-1435, DDN Network Information Center, March 1993.
[MS95] Perry Metzger & Bill Simpson, "IP Authentication with Keyed MD5",
Work in Progress, 21 March 1995.
[MD90] Jeff Mogul & Steve Deering, "Path MTU Discovery", RFC-1191,
DDN Network Information Center, November 1990.
[STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2,
DDN Network Information Center, 20 October 1994.
[Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information
Center, April 1992.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks",
ACM Computing Surveys, Vol. 15, No. 2, June 1983.
DISCLAIMER
The views and specification here are those of the author and are not
necessarily those of his employer. The Naval Research Laboratory has
not passed judgement on the merits, if any, of this work. The author
and his employer specifically disclaim responsibility for any problems
Atkinson [Page 10]
Internet Draft IP Authentication Header 25 April 1995
arising from correct or incorrect implementation or use of this
specification.
AUTHOR INFORMATION
Randall Atkinson <atkinson@itd.nrl.navy.mil>
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA
Phone: (DSN) 354-8590
Fax: (DSN) 354-7942
Atkinson [Page 11]