The Authentication Header (AH) is an IPSec protocol used to provide data integrity, data origin authentication, and limited antireplay (the antireplay is optional) services to IP. AH does not provide any encryption services.
Since AH does not provide confidentiality, it does not require a cipher algorithm. It does, though, require an authenticator. AH defines the method of protection, the placement of the header, the authentication coverage, and input and output processing rules, but it does not define the authentication algorithm to use. Like its sibling protocol, ESP, AH does not mandate antireplay protection. The use of the antireplay services are solely at the discretion of the recipient and there is no way for a sender to know whether a receiver will check the sequence number. Consequently, the sender must always assume that antireplay services is being employed by the recipient.
AH can be used to protect an upper-layer protocol (transport mode) or an entire IP datagram (tunnel mode), just like ESP. In either case the AH header immediately follows an IP header. AH is defined over IP and an AH-protected IP packet is just another IP packet. Therefore, AH can be used alone or in conjunction with ESP. It can protect a tunneling protocol like L2TP or GRE or it can be used to tunnel packets. Like ESP, AH is a versatile security service for IP.
The data integrity that AH provides is subtly different than that provided by ESP; AH authenticates portions of the outer IP header as well.
AH is another IP protocol and has been assigned the number fifty-one (51). The protocol field of an AH-protected IPv4 datagram is 51 indicating that following the IP header is an AH header. In case of IPv6, the value of the next header field depends on the presence of extension headers. In the absence of extension headers, the next header field in the IPv6 header will be 51. In the presence of extension headers prior to the AH header, the next header field in the extension header immediately preceding the AH header is set to 51. The rules for inserting the AH header in IPv6 is similar to that described for ESP. When AH and ESP are protecting the same data, the AH header is always inserted after the ESP header. The AH header is much simpler than the ESP header because it does not provide confidentiality. There is no trailer as there is no need for padding and a pad length indicator. There is also no need for an initialization vector. The AH header is shown in Figure 6.1.
The next header field indicates what follows the AH header. In transport mode it will be the value of the upper-layer protocol being protected, for instance UDP or TCP. In tunnel mode, the value is 4 indicating IP-in-IP (IPv4) encapsulation or 41 for IPv6 encapsulation.
The payload length field indicates the length of the payload itself in 32-bit words minus two. AH is an IPv6 extension header, and according to RFC2460 its length is calculated by subtracting one 64-bit word from the length of the header in 64-bit words. But AH is measured in 32-bit words so we subtract two 32-bit words (or one 64-bit word). The reserved field is not used and must be set to zero.
The SPI field contains the SPI that, along with the destination address of the outer IP header, is used to identify the security association used to authenticate this packet.
The sequence number is a monotonically increasing counter that is identical to that used in ESP. Chapter 3 describes the antireplay function that the sequence number provides.
The authentication data field is a variable length field that contains the result of the integrity checking function. AH does not define an authenticator, but there are two mandatory-to-implement authenticators: HMAC-SHA-96 and HMAC-MD5-96. Like ESP, these are keyed MAC functions whose output is truncated to 96 bits. No public key authentication algorithms (like RSA or DSS) have been defined for use with AH. This is due to the cost; public key algorithms are too slow for bulk data authentication. In certain situations, such as network bootstrapping or the sending of SNMP traps, there is no bulk data protection and this limitation may not apply. For just this reason there is work being done to define the use of DSS with AH.
AH can be used in either transport or tunnel mode, just like ESP. The difference is the data being protected, either an upper-layer protocol or an entire IP datagram.
When used in transport mode, AH protects end-to-end communication. The communications endpoint must be IPSec endpoint. The AH header is inserted into the datagram by placing it immediately following the IP header (and any options) and before the upper-layer protocol header.
When used in tunnel mode, AH encapsulates the protected datagram. An additional IP header is added before the AH header after that. The “internal” IP datagram maintains the original addressing of the communication and the “outer” IP datagram contains the addresses of the IPSec endpoints. Tunnel mode can be used as a replacement to transport mode for end-to-end security. However, as there is no confidentiality and therefore no protection against traffic analysis, it is pointless. AH is used only to guarantee that the received packet was not modified in transit, that it was sent by the party claiming to have sent it, and, optionally, that it is a fresh, nonreplayed packet.
When an outbound packet matches an SPD entry indicating protection with AH, the SADB is queried to see whether a suitable SA exists. If there is no SA, IKE can be used to dynamically create one. If there is an SA, AH is applied to the matched packet in the mode dictated by the SPD entry. If there is an SPD bundle, the order of application depends on the protocols involved. AH always protects ESP, not the other way around.
As mentioned in Chapter 3, when an outbound SA is created—either manually or by IKE—the sequence number counter is initialized to zero. Prior to construction of an AH header using this SA, the counter is incremented. This guarantees that the sequence number in each AH header will be a unique, nonzero, and a monotonically increasing number.
The remaining fields of the AH header are filled in with their appropriate value—the SPI field is assigned the SPI from the SA; the next header field is assigned the value of the type of data following the AH header; and the payload length is assigned the number of 32-bit-words-minus-two value discussed above; and the authentication data field is set to zero.
Unlike ESP, AH extends its protection to immutable or predictable fields of the outer IP header. It is therefore necessary to zero out the mutable fields prior to computation of the Integrity Check Value (ICV). The mutable fields of an IPv4 header that are not included in the authenticating ICV (and are therefore “unprotected”) are the shaded fields in Figure 6.4.
For IPv4 options or IPv6 extension headers, if they are immutable or predictable, they are included in the computation of the ICV. Otherwise, it is necessary to zero them out before computing the ICV.
Padding may be needed depending on the requirements of the authenticator or for alignment reasons. Some MACs—for instance, DES-CBC MAC—require the data over which the MAC is applied be a multiple of the algorithm's block size. In this case padding must be added to properly use the MAC. (Note that neither of the mandatory algorithms have this requirement.) This padding is implicitly added. It must be entirely of the value “zero”, and its size is not included in the payload length and is not transmitted with the packet.
The AH header must be a multiple of 32 bits for IPv4 and 64 bits for IPv6. If the output of the MAC is such that this requirement is not met, the AH header must be padded. There is no requirement on the value of the pad, but it must be included in the ICV calculations and the pad size must be reflected in the payload length. The mandatory-to-implement authenticators are properly aligned, so no padding is needed when using HMAC-MD5-96 or HMAC-SHA-96.
The ICV is calculated by passing the key from the SA and the entire IP packet (including the AH header) to the algorithm identified as the authenticator in the SA. Since the mutable fields have been zeroed out the actual values are not included in the ICV. The ICV value is then copied into authentication data field of the AH and the mutable fields in the IP header can be filled in.
AH processing is now complete and the AH-protected IP packet can be transmitted. Depending on the size of the packet, it might be fragmented prior to placing on the wire or it might be fragmented in transit by routers between the two IPSec peers. This is not a problem and is taken care of during input processing.
Reassembly may be required prior to AH input processing if the protected packet was fragmented prior to its receipt. This is a fairly obvious requirement since the ICV check will fail unless it is done on exactly the same data from which the ICV was generated. The Authentication Header document (RFC2402) notes that the current specification of IPv4 does not require the offset field to be zeroed or the more fragments flag to be cleared after reassembly. AH therefore imposes this requirement on reassembly to guarantee that the inbound packet resembles the outbound packet the peer sent. A fully-formed, AH-protected IP packet can then be passed on to AH input processing.
The first thing to do when processing any IPSec packet is to find the SA that was used to protect it, and AH is no different than ESP in this respect. The SA is, again, identified by the destination address of the IP header, the protocol (in this case 51), and the SPI from the AH header. If no SA is found, the packet is discarded.
Once the SA is found, a sequence number check is made. This step is optional but the cost-to-benefit ratio is so low that there is really no reason not to perform an antireplay check. The antireplay check (described in Chapter 3) determines whether this packet is new or received too late. If it fails this check it is discarded.
The ICV must now be checked. First, the ICV value in the authentication data field of the AH header is saved and that field is zeroed. All mutable fields in the IP are also zeroed (these are the same fields, described above, that were zeroed prior to ICV calculation). If the authenticator algorithm and payload length are such that implicit padding is required to bring the size of the data authenticated up to the requirements of the algorithm, implicit padding is added. This implicit padding must contain the value zero. The authenticator algorithm is then applied to the entire packet and the resulting digest is compared to the saved ICV value. If they match, the IP packet has been authenticated; if they do not match the packet must be discarded.
Once the ICV has been verified, the sequence number of the sliding receive window can be advanced if necessary. This concludes AH processing. The saved IP header can then be restored—remember that the mutable fields were zeroed out and this would prevent further processing—and the entire authenticated datagram can be passed to IP processing.