Network Working Group Randall Atkinson
Internet Draft cisco Systems
draft-ietf-ipsec-auth-header-00.txt 4 June 1996
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 inserted after the IP header being authenticated and before
the other information being authenticated.
1. INTRODUCTION
The Authentication Header is a mechanism for providing strong
integrity, authentication, and replay protection for IP datagrams.
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
Atkinson [Page 1]
Internet Draft IP Authentication Header 4 June 1996
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",
"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 ignore the Authentication Data. When used with
IPv6, the Authentication Header is placed after the Fragmentation and
End-to-End headers and before the 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
and the "Don't Fragment" bit must be set when intermediate
Atkinson [Page 2]
Internet Draft IP Authentication Header 4 June 1996
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]
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. SECURITY ASSOCIATION MANAGEMENT
Security association management is an important part of the IP
security architecture. It is important for AH to be able to work
with multiple security association management protocols (e.g. unicast
vs. multicast). Also, there is a long history in the public
literature of subtle flaws in key management algorithms and
protocols. Hence, the IP Authentication Header tries to decouple the
security association management mechanisms from the security protocol
mechanisms. The only coupling between the key management protocol
and the security protocol is with the Security Parameters Index
(SPI), which is described in more detail below. This decoupling
permits several different security management mechanisms to be used.
More importantly, it permits the security or key management protocol
to be changed or corrected without unduly impacting the security
protocol implementations.
The security management mechanism is used to negotiate a number of
parameters for each "Security Association", including not only the
Atkinson [Page 3]
Internet Draft IP Authentication Header 4 June 1996
keys but also other information (e.g. the authentication algorithm
and mode) used by the communicating parties. The security 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).
Security Associations are unidirectional. A bidirectional
communications session will normally have one Security Association in
each direction. For example, when a TCP session exists between two
systems A and B, there will normally be one Security Association from
A to B and a separate second Security Assocation from B to A. The
receiver assigns the SPI value to the the Security Association with
that sender. The other parameters of the Security Association are
determined in a manner specified by the security management
mechanism. Section 4 of this document describes in detail the
process of selecting a Security Association for an outgoing packet
and identifying the Security Assocation for an incoming packet.
The IP Security Architecture document describes key management in
more detail. It includes specification of the key management
requirements for implementations of this protocol, and is
incorporated here by reference. [Atk95a]
3. AUTHENTICATION HEADER SYNTAX
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] Note that AH
uses daisy-chained optional headers even for IPv4 just as IPv6 daisy-
chains all optional headers.
The following header combinations are NOT valid at any time:
1. [IP][AH][AH][upper-layer protocol]
2. [IP][ESP][AH][upper-layer protocol]
Regarding case 1, one should only have a single AH present in such a
packet. Regarding case 2, one instead uses an ESP transform (e.g.
[Hugh96]) that provides strong integrity and authentication
protections in addition to confidentiality.
Example high-level diagrams of valid IP datagrams with the
Authentication Header follow.
+-------------+--------------------+-------------+--------+----------------+
Atkinson [Page 4]
Internet Draft IP Authentication Header 4 June 1996
| IPv6 Header | Hop-by-Hop/Routing | Auth Header | Others | Upper Protocol |
+-------------+--------------------+-------------+--------+----------------+
Figure 1: IPv6 Example
Atkinson [Page 5]
Internet Draft IP Authentication Header 4 June 1996
When used with IPv6, the Authentication Header normally appears after the
IPv6 Hop-by-Hop Header and the Fragmentation Header and just before the
IPv6 Destination Options Header. If neither the Hop-by-Hop Header nor
the Fragmentation Header are present in the packet, the Authentication
Header might not directly follow such (in that case, non-existent) headers.
The Authentication Header does always fall in that logical position within
the IP packet. Fragmentation always occurs after AH processing and
reassembly occurs before AH processing, so if the Fragmentation Header
exists in a packet the Authentication Header MUST NOT precede the
Fragmentation Header.
+-------------+--------------+-------------------------------+
| IPv4 Header | Auth Header | Upper Protocol (e.g TCP, UDP) |
+-------------+--------------+-------------------------------+
Figure 2: IPv4 Example
When used with IPv4, the Authentication Header MUST immediately follow
the IPv4 header, unless an in-line IP-layer key management technique
is in use for that packet. In the latter case, the Authentication
Header MUST always follow that inline IP-layer key management header.
It is NOT valid in any other location.
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
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) |
| |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Atkinson [Page 6]
Internet Draft IP Authentication Header 4 June 1996
Figure 3: Authentication Header syntax
3.2 Fields of the Authentication Header
NEXT HEADER
8 bits wide. Identifies the next payload after the Authentication
Header. The 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
16 bits wide. Reserved for future use. MUST be set to all zeros
when sent. The value is included in the Authentication Data
calculation, but is otherwise ignored by the recipient.
SECURITY PARAMETERS INDEX (SPI)
An arbitrary 32-bit value identifying the security association
for this datagram. The Security 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.
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. The value of the padding field is arbitrarily selected
by the sender and is included in the Authentication Data calculation.
An implementation will 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.
Atkinson [Page 7]
Internet Draft IP Authentication Header 4 June 1996
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.
Refer to each Authentication Transform 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 carried by the IP Authentication Header 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 the
IP Authentication Header.
Because conventional checksums and CRCs are not cryptographically strong,
they MUST NOT be used with the Authentication Header.
When processing an outgoing IP packet for Authentication, the first step
is for the sending system to locate the appropriate Security Association.
All Security Associations are unidirectional. The selection of the
appropriate Security Association for an outgoing IP packet originating at
this system is based at least upon the sending userid and the Destination
Address. For traffic not originating on the security gateway that is
adding the IP Authentication Header, the security gateway should select an
appropriate Security Association based on the source and destination
address, upper-layer protocol, and port triple. 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
Atkinson [Page 8]
Internet Draft IP Authentication Header 4 June 1996
users will use different Security Associations. When session-unique keying
is in use, different applications of the same user on different sockets
will use different Security Associations. The Security Association
selected will indicate which algorithm, algorithm mode, key, and other
security properties apply to the outgoing packet.
Fields which NECESSARILY are modified during transit from the sender
to the receiver (e.g. TTL and HEADER CHECKSUM for IPv4 or Hop Limit
for IPv6) and whose value at the receiver are not known with certainty
by the sender are included in the authentication data calculation but
are processed specially. For these fields which are modified during
transit, the value carried in the IP packet is replaced by the value
zero for the purpose of the authentication calculation. By replacing
the field's value with zero rather than omitting these fields,
alignment is preserved for the authentication calculation.
The sender MUST compute the authentication over the packet as that
packet 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. This also permits the
authentication of data that will vary in transit but whose value at
the final receiver is known with certainty by the sender in advance.
The sender places the calculated authentication data into the
Authentication Data field within the Authentication Header. For purposes
of Authentication Data computation, the Authentication Data field is
considered to be filled with zeros.
The IPv4 "TIME TO LIVE","HEADER CHECKSUM", "FLAGS", and "TYPE OF SERVICE"
fields are the only fields in the IPv4 base header that are handled
specially for the Authentication Data calculation. Reassembly of
fragmented packets occurs PRIOR to processing by the local IP
Authentication Header implementation. The "more" bit is of course cleared
upon reassembly.
Hence, no other fields in the IPv4 header will vary in transit from the
perspective of the IP Authentication Header implementation. The specially
handled field enumerated above MUST be set to all zeros for the
Authentication Data calculation. All other IPv4 base header fields are
processed normally with their actual contents. Because IPv4 packets are
subject to intermediate fragmentation in routers, it is important that the
reassembly of IPv4 packets be performed prior to the Authentication Header
processing. IPv4 Implementations SHOULD use Path MTU Discovery when the IP
Authentication Header is being used. [MD90] For IPv4, options are normally
zeroed for the purpose of the Authentication Data calculation. There are
two exceptions to this rule. The IP Security Option (IPSO) MUST be
included in the Authentication Data calculation whenever that option is
Atkinson [Page 9]
Internet Draft IP Authentication Header 4 June 1996
present in an IP datagram. [Ken91] The undocumented non-standard CIPSO
option, which has been assigned option number 134 by IANA, also MUST be
included in the Authentication data calculation whenever that option is
present in an IP datagram. If a receiving system does not recognise an
IPv4 option that is present in the packet, that option is omitted from
Authentication Data calculation.
The IPv6 "HOP LIMIT" field is the only field in the IPv6 base header
that is handled specially for Authentication Data calculation. The
value of the HOP LIMIT field is zero for the purpose of Authentication
Data calculation. All other fields in the base IPv6 header MUST be
included in the Authentication Data calculation using the normal
procedures for calculating the Authentication Data. All IPv6 "OPTION
TYPE" values contain a bit which MUST be used to determine whether
that option data will be included in the Authentication Data
calculation. This bit is the third-highest-order bit of the IPv6
OPTION TYPE field. If this bit is set to zero, then the corresponding
option is included in the Authentication Data calculation. If this
bit is set to one, then the corresponding option is replaced by all
zero bits of the same length as the option for the purpose of the
Authentication Data calculation. The IPv6 Routing Header "Type 0"
will rearrange the address fields within the packet during transit
from source to destination. However, this is not a problem because
the contents of the packet as it will appear at the receiver are known
to the sender and to all intermediate hops. Hence, the IPv6 Routing
Header "Type 0" is included in the Authentication Data calculation
using the normal procedure.
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
verifies that the Authentication Data field and the received data
packet are consistent. Again, the Authentication Data field is
assumed to be zero for the sole purpose of making the authentication
computation. Exactly how this is accomplished is algorithm dependent.
If the processing of the authentication algorithm indicates the
datagram is valid, then it is accepted. If the algorithm determines
that the data and the Authentication Header do not match, then the
receiver MUST discard the received IP datagram as invalid and MUST
record the authentication failure in the system log or audit log. If
such a failure occurs, the recorded log data MUST include the SPI
value, date/time received, clear-text Sending Address, clear-text
Destination Address, and (if it exists) the clear-text Flow ID. The
log data MAY also include other information about the failed packet.
Atkinson [Page 10]
Internet Draft IP Authentication Header 4 June 1996
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 Architecture for the Internet Protocol"
[Atk95a], and MUST support the use of the mandatory-to- implement AH
transforms. As of this writing these are HMAC SHA [CG96] and HMAC MD5
[OG96], but implementers need to consult the most recent version of the
"Internet Official Protocol Standards" [STD-1] for current information on
standards status. Implementations MAY also implement other authentication
algorithms.
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. Implementors are encouraged to use high
assurance methods to develop all of the security relevant parts of
their products.
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
Atkinson [Page 11]
Internet Draft IP Authentication Header 4 June 1996
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].
The use of IP tunneling with AH creates multiple pairs of endpoints
that might perform AH processing. Implementers and administrators
should carefully consider the impacts of tunneling on authenticity of
the received tunneled packets.
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
[Atk96a] Randall Atkinson, Security Architecture for the Internet Protocol,
Internet Draft, 4 June 1996
[Atk96b] Randall Atkinson, IP Encapsulating Security Payload, Internet Draft,
4 June 1996
[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.
Atkinson [Page 12]
Internet Draft IP Authentication Header 4 June 1996
Available via anonymous ftp from info.cert.org in /pub/cert_advisories.
[CG96] Shu-jen Chang & Rob Glenn, "HMAC SHA IP Authentication with Replay
Protection", Internet Draft, 1 May 1996.
[DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6)
Specification", RFC-1883, December 1995.
[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.
[Hugh96] Jim Hughes (Editor), "Combined DES-CBC, HMAC, and Replay
Prevention Security Transform", Internet Draft, April 1996.
[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.
[MD90] Jeff Mogul & Steve Deering, "Path MTU Discovery", RFC-1191,
DDN Network Information Center, November 1990.
[OG96] Mike Oehler & Rob Glenn, "HMAC SHA IP Authentication with Replay
Protection", Internet Draft, May 1996.
[STD-1] J. Postel, "Internet Official Protocol Standards", STD-1,
DDN Network Information Center, March 1996.
[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 author and his employer
specifically disclaim responsibility for any problems arising from correct
or incorrect implementation or use of this specification.
Atkinson [Page 13]
Internet Draft IP Authentication Header 4 June 1996
AUTHOR INFORMATION
Randall Atkinson <rja@cisco.com>
cisco Systems
170 West Tasman Drive
San Jose, CA, 95134-1706
USA
Telephone: +1 (408) 526-4000
Atkinson [Page 14]