IP Authentication Header
obsoleted by
- rfc-2402 — IP Authentication Header
Extracted elements (27)
Authentication data is carried in its own payload so that systems not participating in authentication MAY simply ignore the Authentication Data, preserving backward compatibility without requiring changes to the broader Internet infrastructure.
Key management is intentionally decoupled from the Authentication Header protocol. The only coupling is the SPI value. This permits different key management mechanisms to be used and allows the key management protocol to be changed or corrected without impacting AH implementations.
Mutable fields that change in transit are replaced by zero in the authentication calculation rather than being omitted entirely. Zeroing instead of omitting preserves byte alignment for the authentication calculation.
The Authentication Header deliberately omits confidentiality and traffic analysis protection so that it remains a separable, composable component. Users requiring confidentiality are directed to the IP Encapsulating Security Payload (ESP, RFC 1827).
Reassembly of fragmented IPv4 packets MUST occur prior to Authentication Header processing by the local implementation. Because IPv4 packets may be subject to intermediate fragmentation in routers, this ordering is critical for correct authentication.
The IPv6 Routing Header Type 0 rearranges address fields during transit, but its final state at the receiver is known to the sender and all intermediate hops; therefore it is included in the Authentication Data calculation using the normal procedure rather than being zeroed.
All implementations MUST support padding of the Authentication Data field to alignments (e.g., 64-bit) as specified by the Destination on a per-SPI basis. The padding value is chosen by the sender and is included in the authentication calculation.
Conventional checksums such as CRC-16 are not cryptographically strong and MUST NOT be used with the Authentication Header.
For IPv4, the TIME TO LIVE and HEADER CHECKSUM fields MUST be set to all zeros for the Authentication Data calculation; all other IPv4 base header fields are processed normally with actual contents.
For IPv6, the HOP LIMIT field is zeroed for Authentication Data calculation. Each IPv6 OPTION TYPE's third-highest-order bit MUST be used to determine whether the option is included (bit=0) or replaced by zeros (bit=1) in the calculation.
If explicit IP sensitivity labels (e.g., IPSO per RFC 1108) are present, they MUST be included in the Authentication Data calculation. The IP Security Option (IPSO) MUST be included whenever it is present.
Implementations claiming conformance MUST fully implement the Authentication Header, MUST support manual key distribution, MUST comply with the IP Security Architecture (RFC 1825), and MUST support keyed MD5 as described in RFC 1828.
IPv4 implementations SHOULD use Path MTU Discovery when the IP Authentication Header is in use, because IPv4 packets subject to intermediate fragmentation must be reassembled prior to AH processing.
On authentication failure, the receiver SHOULD discard the IP datagram and MUST record the failure in the system or audit log, including SPI, date/time, clear-text sending address, clear-text destination address, and (if present) clear-text Flow ID.
Path MTU Discovery MUST be used when intermediate authentication of the Authentication Header is desired with IPv4, because it is not possible to authenticate a fragment of a packet.
The RESERVED field MUST be set to all zeros when sent. Its value is included in the Authentication Data calculation but is otherwise ignored by the recipient.
The sender MUST compute the authentication data over the packet exactly as it will appear at the receiver, including any optional headers the sender includes but the receiver might not process.
The Authentication Data field is variable-length (integral number of 32-bit words) and holds the output of the authentication algorithm. Its size and use are determined per SPI and Destination Address pair; padding to 64-bit alignment is common.
The IP protocol number 51 is used in the Next Header (or Protocol) field of the immediately preceding IPv4 or IPv6 header to indicate the presence of an Authentication Header.
The Security Parameters Index (SPI) is a 32-bit pseudo-random value identifying the Security Association for a datagram. SPI value 0 is reserved to indicate no security association exists; values 1–255 are reserved to IANA for future use.
SPI value 0 is permanently reserved to mean 'no security association exists'. SPI values 1 through 255 are reserved to IANA for future use and will only be assigned if openly specified in an RFC.
Active attacks (IP spoofing, session hijacking) are known to exist on the Internet. Unauthenticated source routing represents a significant security risk; all source-routed packets should be authenticated with AH or another cryptographic mechanism.
The security quality provided by AH depends entirely on the strength of the cryptographic algorithm, strength of the key, correctness of the algorithm's implementation, security of the key management mechanism, and correctness of the IP and AH implementations in all participating systems. Weakness in any of these components renders the protection ineffective.
Use of IP tunneling with AH creates multiple pairs of endpoints that might each perform AH processing. Implementers and administrators must carefully consider the impacts of tunneling on the authenticity of received tunneled packets.
When a packet causes an ICMP error and is too large to fit entirely within the ICMP reply, the receiver of the ICMP message may be unable to authenticate the returned portion, forcing a choice between trusting an unauthenticated ICMP message or ignoring a legitimate one.
Outgoing packet processing: (1) locate the appropriate Security Association using sending userid and Destination Address; (2) zero mutable fields; (3) compute authentication data over the packet as it will appear at the receiver; (4) insert result into the Authentication Data field. Incoming packet processing: (1) use Destination Address and SPI to locate the Security Association; (2) independently verify the Authentication Data field; (3) accept or discard and log.
The Authentication Header consists of a 8-bit Next Header field, 8-bit Payload Length field, 16-bit RESERVED field, 32-bit Security Parameters Index (SPI), and a variable-length Authentication Data field containing an integral number of 32-bit words.