Request for Comments: 4302 BBN Technologies
Obsoletes: 2402 December 2005
Category: Standards Track
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.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an updated version of the IP Authentication
Header (AH), which is designed to provide authentication services in
IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).
Table of Contents
1. Introduction ....................................................3
2. Authentication Header Format ....................................4
2.1. Next Header ................................................5
2.2. Payload Length .............................................5
2.3. Reserved ...................................................6
2.4. Security Parameters Index (SPI) ............................6
2.5. Sequence Number ............................................8
2.5.1. Extended (64-bit) Sequence Number ...................8
2.6. Integrity Check Value (ICV) ................................9
3. Authentication Header Processing ................................9
3.1. Authentication Header Location .............................9
3.1.1. Transport Mode ......................................9
3.1.2. Tunnel Mode ........................................11
3.2. Integrity Algorithms ......................................11
3.3. Outbound Packet Processing ................................11
3.3.1. Security Association Lookup ........................12
3.3.2. Sequence Number Generation .........................12
3.3.3. Integrity Check Value Calculation ..................13
3.3.3.1. Handling Mutable Fields ...................13
3.3.3.2. Padding and Extended Sequence Numbers .....16
3.3.4. Fragmentation ......................................17
3.4. Inbound Packet Processing .................................18
3.4.1. Reassembly .........................................18
3.4.2. Security Association Lookup ........................18
3.4.3. Sequence Number Verification .......................19
3.4.4. Integrity Check Value Verification .................20
4. Auditing .......................................................21
5. Conformance Requirements .......................................21
6. Security Considerations ........................................22
7. Differences from RFC 2402 ......................................22
8. Acknowledgements ...............................................22
9. References .....................................................22
9.1. Normative References ......................................22
9.2. Informative References ....................................23
Appendix A: Mutability of IP Options/Extension Headers ............25
A1. IPv4 Options ...............................................25
A2. IPv6 Extension Headers .....................................26
Appendix B: Extended (64-bit) Sequence Numbers ....................28
B1. Overview ...................................................28
B2. Anti-Replay Window .........................................28
B2.1. Managing and Using the Anti-Replay Window ............29
B2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................30
B2.3. Pseudo-Code Example ..................................31
B3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................32
B3.1. Triggering Re-synchronization ........................33
B3.2. Re-synchronization Process ...........................33
1. Introduction
This document assumes that the reader is familiar with the terms and
concepts described in the "Security Architecture for the Internet
Protocol" [Ken-Arch], hereafter referred to as the Security
Architecture document. In particular, the reader should be familiar
with the definitions of security services offered by the
Encapsulating Security Payload (ESP) [Ken-ESP] and the IP
Authentication Header (AH), the concept of Security Associations, the
ways in which ESP can be used in conjunction with the Authentication
Header (AH), and the different key management options available for
ESP and AH.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [Bra97].
The IP Authentication Header (AH) is used to provide connectionless
integrity and data origin authentication for IP datagrams (hereafter
referred to as just "integrity") and to provide protection against
replays. This latter, optional service may be selected, by the
receiver, when a Security Association (SA) is established. (The
protocol default requires the sender to increment the sequence number
used for anti-replay, but the service is effective only if the
receiver checks the sequence number.) However, to make use of the
Extended Sequence Number feature in an interoperable fashion, AH does
impose a requirement on SA management protocols to be able to
negotiate this new feature (see Section 2.5.1 below).
AH provides authentication for as much of the IP header as possible,
as well as for next level protocol data. However, some IP header
fields may change in transit and the value of these fields, when the
packet arrives at the receiver, may not be predictable by the sender.
The values of such fields cannot be protected by AH. Thus, the
protection provided to the IP header by AH is piecemeal. (See
Appendix A.)
AH may be applied alone, in combination with the IP Encapsulating
Security Payload (ESP) [Ken-ESP], or in a nested fashion (see
Security Architecture document [Ken-Arch]). Security services can be
provided between a pair of communicating hosts, between a pair of
communicating security gateways, or between a security gateway and a
host. ESP may be used to provide the same anti-replay and similar
integrity services, and it also provides a confidentiality
(encryption) service. The primary difference between the integrity
provided by ESP and AH is the extent of the coverage. Specifically,
ESP does not protect any IP header fields unless those fields are
encapsulated by ESP (e.g., via use of tunnel mode). For more details
on how to use AH and ESP in various network environments, see the
Security Architecture document [Ken-Arch].
Section 7 provides a brief review of the differences between this
document and RFC 2402 [RFC2402].
2. Authentication Header Format
The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
preceding the AH header SHALL contain the value 51 in its Protocol
(IPv4) or Next Header (IPv6, Extension) fields [DH98]. Figure 1
illustrates the format for AH.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AH Format
The following table refers to the fields that comprise AH,
(illustrated in Figure 1), plus other fields included in the
integrity computation, and illustrates which fields are covered by
the ICV and what is transmitted.
What What
# of Requ’d Integ is
bytes [1] Covers Xmtd
------ ------ ------ ------
IP Header variable M [2] plain
Next Header 1 M Y plain
Payload Len 1 M Y plain
RESERVED 2 M Y plain
SPI 4 M Y plain
Seq# (low-order 32 bits) 4 M Y plain
ICV variable M Y[3] plain
IP datagram [4] variable M Y plain
Seq# (high-order 32 bits) 4 if ESN Y not xmtd
ICV Padding variable if need Y not xmtd
[1] - M = mandatory
[2] - See Section 3.3.3, "Integrity Check Value Calculation", for
details of which IP header fields are covered.
[3] - Zeroed before ICV calculation (resulting ICV placed here
after calculation)
[4] - If tunnel mode -> IP datagram
If transport mode -> next header and data
The following subsections define the fields that comprise the AH
format. All the fields described here are mandatory; i.e., they are
always present in the AH format and are included in the Integrity
Check Value (ICV) computation (see Sections 2.6 and 3.3.3).
Note: All of the cryptographic algorithms used in IPsec expect their
input in canonical network byte order (see Appendix of RFC 791
[RFC791]) and generate their output in canonical network byte order.
IP packets are also transmitted in network byte order.
AH does not contain a version number, therefore if there are concerns
about backward compatibility, they MUST be addressed by using a
signaling mechanism between the two IPsec peers to ensure compatible
versions of AH, e.g., IKE [IKEv2] or an out-of-band configuration
mechanism.
2.1. Next Header
The Next Header is an 8-bit field that identifies the type of the
next payload after the Authentication Header. The value of this
field is chosen from the set of IP Protocol Numbers defined on the
web page of Internet Assigned Numbers Authority (IANA). For example,
a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a
value of 6 indicates TCP.
2.2. Payload Length
This 8-bit field specifies the length of AH in 32-bit words (4-byte
units), minus "2". Thus, for example, if an integrity algorithm
yields a 96-bit authentication value, this length field will be "4"
(3 32-bit word fixed fields plus 3 32-bit words for the ICV, minus
2). For IPv6, the total length of the header must be a multiple of
8-octet units. (Note that although IPv6 [DH98] characterizes AH as
an extension header, its length is measured in 32-bit words, not the
64-bit words used by other IPv6 extension headers.) See Section 2.6,
"Integrity Check Value (ICV)", for comments on padding of this field,
and Section 3.3.3.2.1, "ICV Padding".
2.3. Reserved
This 16-bit field is reserved for future use. It MUST be set to
"zero" by the sender, and it SHOULD be ignored by the recipient.
(Note that the value is included in the ICV calculation, but is
otherwise ignored by the recipient.)
2.4. Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that is used by a receiver to
identify the SA to which an incoming packet is bound. For a unicast
SA, the SPI can be used by itself to specify an SA, or it may be used
in conjunction with the IPsec protocol type (in this case AH).
Because for unicast SAs the SPI value is generated by the receiver,
whether the value is sufficient to identify an SA by itself or
whether it must be used in conjunction with the IPsec protocol value
is a local matter. The SPI field is mandatory, and this mechanism
for mapping inbound traffic to unicast SAs described above MUST be
supported by all AH implementations.
If an IPsec implementation supports multicast, then it MUST support
multicast SAs using the algorithm below for mapping inbound IPsec
datagrams to SAs. Implementations that support only unicast traffic
need not implement this de-multiplexing algorithm.
In many secure multicast architectures, e.g., [RFC3740], a central
Group Controller/Key Server unilaterally assigns the group security
association’s SPI. This SPI assignment is not negotiated or
coordinated with the key management (e.g., IKE) subsystems that
reside in the individual end systems that comprise the group.
Consequently, it is possible that a group security association and a
unicast security association can simultaneously use the same SPI. A
multicast-capable IPsec implementation MUST correctly de-multiplex
inbound traffic even in the context of SPI collisions.
Each entry in the Security Association Database (SAD) [Ken-Arch] must
indicate whether the SA lookup makes use of the destination, or
destination and source, IP addresses, in addition to the SPI. For
multicast SAs, the protocol field is not employed for SA lookups.
For each inbound, IPsec-protected packet, an implementation must
conduct its search of the SAD such that it finds the entry that
matches the "longest" SA identifier. In this context, if two or more
SAD entries match based on the SPI value, then the entry that also
matches based on destination, or destination and source, address
comparison (as indicated in the SAD entry) is the "longest" match.
This implies a logical ordering of the SAD search as follows:
1. Search the SAD for a match on {SPI, destination
address, source address}. If an SAD entry
matches, then process the inbound AH packet with that
matching SAD entry. Otherwise, proceed to step 2.
2. Search the SAD for a match on {SPI, destination
address}. If an SAD entry matches, then process
the inbound AH packet with that matching SAD
entry. Otherwise, proceed to step 3.
3. Search the SAD for a match on only {SPI} if the receiver
has chosen to maintain a single SPI space for AH and ESP,
or on {SPI, protocol} otherwise. If an SAD
entry matches, then process the inbound AH packet with
that matching SAD entry. Otherwise, discard the packet
and log an auditable event.
In practice, an implementation MAY choose any method to accelerate
this search, although its externally visible behavior MUST be
functionally equivalent to having searched the SAD in the above
order. For example, a software-based implementation could index into
a hash table by the SPI. The SAD entries in each hash table bucket’s
linked list are kept sorted to have those SAD entries with the
longest SA identifiers first in that linked list. Those SAD entries
having the shortest SA identifiers are sorted so that they are the
last entries in the linked list. A hardware-based implementation may
be able to effect the longest match search intrinsically, using
commonly available Ternary Content-Addressable Memory (TCAM)
features.
The indication of whether source and destination address matching is
required to map inbound IPsec traffic to SAs MUST be set either as a
side effect of manual SA configuration or via negotiation using an SA
management protocol, e.g., IKE or Group Domain of Interpretation
(GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03]
groups use a 3-tuple SA identifier composed of an SPI, a destination
multicast address, and source address. An Any-Source Multicast group
SA requires only an SPI and a destination multicast address as an
identifier.
The set of SPI values in the range 1 through 255 is reserved by the
Internet Assigned Numbers Authority (IANA) for future use; a reserved
SPI value will not normally be assigned by IANA unless the use of the
assigned SPI value is specified in an RFC. The SPI value of zero (0)
is reserved for local, implementation-specific use and MUST NOT be
sent on the wire. (For example, a key management implementation
might use the zero SPI value to mean "No Security Association Exists"
during the period when the IPsec implementation has requested that
its key management entity establish a new SA, but the SA has not yet
been established.)
2.5. Sequence Number
This unsigned 32-bit field contains a counter value that increases by
one for each packet sent, i.e., a per-SA packet sequence number. For
a unicast SA or a single-sender multicast SA, the sender MUST
increment this field for every transmitted packet. Sharing an SA
among multiple senders is permitted, though generally not
recommended. AH provides no means of synchronizing packet counters
among multiple senders or meaningfully managing a receiver packet
counter and window in the context of multiple senders. Thus, for a
multi-sender SA, the anti-reply features of AH are not available (see
Sections 3.3.2 and 3.4.3).
The field is mandatory and MUST always be present even if the
receiver does not elect to enable the anti-replay service for a
specific SA. Processing of the Sequence Number field is at the
discretion of the receiver, but all AH implementations MUST be
capable of performing the processing described in Section 3.3.2,
"Sequence Number Generation", and Section 3.4.3, "Sequence Number
Verification". Thus, the sender MUST always transmit this field, but
the receiver need not act upon it.
The sender’s counter and the receiver’s counter are initialized to 0
when an SA is established. (The first packet sent using a given SA
will have a sequence number of 1; see Section 3.3.2 for more details
on how the sequence number is generated.) If anti-replay is enabled
(the default), the transmitted sequence number must never be allowed
to cycle. Thus, the sender’s counter and the receiver’s counter MUST
be reset (by establishing a new SA and thus a new key) prior to the
transmission of the 2^32nd packet on an SA.
2.5.1. Extended (64-bit) Sequence Number
To support high-speed IPsec implementations, a new option for
sequence numbers SHOULD be offered, as an extension to the current,
32-bit sequence number field. Use of an Extended Sequence Number
(ESN) MUST be negotiated by an SA management protocol. Note that in
IKEv2, this negotiation is implicit; the default is ESN unless 32-bit
sequence numbers are explicitly negotiated. (The ESN feature is
applicable to multicast as well as unicast SAs.)
The ESN facility allows use of a 64-bit sequence number for an SA.
(See Appendix B, "Extended (64-bit) Sequence Numbers", for details.)
Only the low-order 32 bits of the sequence number are transmitted in
the AH header of each packet, thus minimizing packet overhead. The
high-order 32 bits are maintained as part of the sequence number
counter by both transmitter and receiver and are included in the
computation of the ICV, but are not transmitted.
2.6. Integrity Check Value (ICV)
This is a variable-length field that contains the Integrity Check
Value (ICV) for this packet. The field must be an integral multiple
of 32 bits (IPv4 or IPv6) in length. The details of ICV processing
are described in Section 3.3.3, "Integrity Check Value Calculation",
and Section 3.4.4, "Integrity Check Value Verification". This field
may include explicit padding, if required to ensure that the length
of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits
(IPv6). All implementations MUST support such padding and MUST
insert only enough padding to satisfy the IPv4/IPv6 alignment
requirements. Details of how to compute the required padding length
are provided below in Section 3.3.3.2, "Padding". The integrity
algorithm specification MUST specify the length of the ICV and the
comparison rules and processing steps for validation.
3. Authentication Header Processing
3.1. Authentication Header Location
AH may be employed in two ways: transport mode or tunnel mode. (See
the Security Architecture document for a description of when each
should be used.)
3.1.1. Transport Mode
In transport mode, AH is inserted after the IP header and before a
next layer protocol (e.g., TCP, UDP, ICMP, etc.) or before any other
IPsec headers that have already been inserted. In the context of
IPv4, this calls for placing AH after the IP header (and any options
that it contains), but before the next layer protocol. (Note that
the term "transport" mode should not be misconstrued as restricting
its use to TCP and UDP.) The following diagram illustrates AH
transport mode positioning for a typical IPv4 packet, on a "before
and after" basis.
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
-------------------------------------------------------
IPv4 |original IP hdr (any options) | AH | TCP | Data |
-------------------------------------------------------
|<- mutable field processing ->|<- immutable fields ->|
|<----- authenticated except for mutable fields ----->|
In the IPv6 context, AH is viewed as an end-to-end payload, and thus
should appear after hop-by-hop, routing, and fragmentation extension
headers. The destination options extension header(s) could appear
before or after or both before and after the AH header depending on