Given that one of the preferred methods for spies and cyber-attackers is to intercept a data stream as it moves from its source to its destination, information security practitioners have to focus much of their effort on ensuring the integrity of data in transit. The Authentication Header is an important part of this.
What is an Authentication Header?
An Authentication Header or AH is a security mechanism used in authenticating the origins of datagrams (packets of data transmitted under Internet Protocol or IP conditions), and in guaranteeing the integrity of the information that’s being sent. Authentication Headers are a protocol under the Internet Protocol Security (IPSec) suite.
When a datagram is sent across the internet, it consists of a payload (the main body of the data itself) and a header (a prefix describing and identifying the packet being sent). An Authentication Header verifies the original source of the packet and ensures that both payload and header have not been altered during transmission.
Placement of an Authentication Header between a datagram’s IP header and transport protocol header (layer 4) provides authentication and ensures integrity. An AH must be inserted after the IP header and before any upper layer security protocol such as UDP, TCP, or IDMP. The Authentication Header must also be inserted before any other IPSec header if a combination of security protocols is being used.
Fields Within an Authentication Header
There are several fields which make up a complete Authentication Header. These include:
Next Header: This identifies the next header that will use the specified IP protocol ID (or encapsulated protocol). It has a maximum length of 8 bits.
Payload Length: This indicates the length of the Authentication Header, in 32-bit words.
Security Parameters Index (SPI): In conjunction with a packet’s destination address and the security protocol being used (typically AH or Encapsulating Security Payload ESP), this identifies the appropriate security association for the data transmission. At the destination, the receiver uses this information to determine which security association has been used to identify the packet.
Sequence Number: This provides protection against replay attacks, such as those in which an intercepted or captured data stream is continually sent to the same server to precipitate a Denial of Service. The Sequence Number’s length may vary, but it has to be a multiple of 32-bit words which once set cannot be allowed to cycle. It indicates the packet number that’s been sent over by the security association (SA) for a particular communication. At the receiving end, the Sequence Number may be checked to verify that a packet for its specified security association has not been received before. The packet is rejected, if a datagram with that association has already been received.
Integrity Check Value (ICV): This is authentication data used to verify the integrity of a transmission. The recipient calculates a hash value and compares it to this ICV number (which was calculated by the sender) to verify the message’s integrity.
When used in transport mode, the description of a datagram occurs with its IP header as the outermost identifier, followed by the Authentication Header, then the datagram itself.
In tunnel mode, new IP headers are created dynamically and used in the outermost IP header of a data packet. Authentication Headers may still be used, but this method demands considerably more processor power than transport mode communications.
Ensuring Data Integrity
Authentication Headers ensure data integrity through the use of checksums generated via an authentication code. HMAC algorithms are used to sign data packets for integrity.
To authenticate a datagram’s origin, the Authentication Header algorithm incorporates a secret shared key. Relay protection is assured through the Sequence Number field of the Authentication Header.
At the receiver’s discretion, Authentication Headers may offer an anti-replay service (partial sequence integrity), as a hedge against Denial of Service or DoS attacks.
Authentication Headers may also be deployed to provide protection for selected parts of an IP header, as for example where the integrity of an IPv6 extension header or an IPv4 option has to be protected in transit.
Encapsulating Security Payload (ESP)
Authentication Headers may be used on their own, or in conjunction with the Encapsulating Security Payload (ESP) protocol. Security services may be initiated between two communicating hosts, between two communicating security gateways, or between a host and a gateway.
Placement and Linking
IPv4 and IPv6 use different methods for placing an Authentication Header into a datagram, and for linking its various headers together. But the AH protocol was essentially designed to use the IPv6 mechanism, which inserts an Authentication Header into the IP datagram as an extension header, according to IPv6 rules for linking extension headers.
The AH is linked by the previous (extension or main) header, which puts the assigned value of the Authentication Header into its Next Header field. The AH in turn links to the next extension header or transport layer header via its own Next Header field.
Authentication Headers provide authentication, integrity, and (when specified) anti-replay protection for entire data packets. However, they don’t ensure confidentiality, as the AH protocol has no native provision for encrypting data transmissions. Packets protected by an Authentication Header are protected from being modified, but they are still readable to anyone who might happen to gain access to them.
So for situations where confidentiality isn’t a requirement or where legal restrictions on encryption may be imposed, Authentication Headers are an appropriate solution. If however encryption is required, then an auxiliary protocol such as ESP (which does provide an encryption service) must be considered.
Share this Post