Protokół Authentication Header (AH) zapewnia uwierzytelnianie pochodzenia danych, ich integralność oraz ochronę odpowiedzi. Nie gwarantuje on jednak poufności danych, ponieważ przesyła je w postaci jawnej.
Integralność danych w protokole AH jest realizowana za pomocą sumy kontrolnej generowanej przez kody uwierzytelniania komunikatu, na przykład MD5. Do uwierzytelniania pochodzenia danych protokół AH używa tajnego klucza wspólnego w swoim algorytmie uwierzytelniania. Do ochrony odpowiedzi protokół AH używa pola z numerem kolejnym w nagłówku AH. Warto tutaj zauważyć, że te trzy różne funkcje są często łączone i określane jako uwierzytelnianie. Mówiąc najprościej, AH gwarantuje, że nie manipulowano danymi w drodze do ich miejsca przeznaczenia.
Mimo że protokół AH uwierzytelnia maksymalną możliwą część datagramu IP, odbiorca nie może przewidzieć wartości niektórych pól z nagłówka IP. AH nie chroni tych pól, zwanych polami zmiennymi. Protokół ten zawsze jednak chroni dane ładunku w pakiecie IP.
Formalna definicja protokołu AH została opublikowana przez grupę wykonawczą IETF (Internet Engineering Task Force) w dokumencie Request for Comment (RFC) 4302 zatytułowanym IP Authentication Header. Dokument ten jest dostępny w serwisie WWW pod adresem http://www.rfc-editor.org.
Metody korzystania z protokołu AH
Protokół AH można stosować na dwa sposoby: w trybie transportowym lub w trybie tunelowym. W trybie transportowym nagłówek IP datagramu jest nagłówkiem zewnętrznym, po którym następuje nagłówek AH, a potem dane ładunku datagramu. Protokół AH uwierzytelnia cały datagram z wyjątkiem pól zmiennych. Jednak informacje zawarte w datagramie są transportowane w postaci jawnej, co stwarza ryzyko ich przechwycenia. Obciążenie związane z trybem transportowym jest mniejsze niż w przypadku trybu tunelowego, jednak ochrona w tym trybie jest słabsza niż w trybie tunelowym.
W trybie tunelowym tworzony jest nowy nagłówek IP, który jest używany jako zewnętrzny nagłówek IP datagramu. Nagłówek AH jest umieszczany po nowym nagłówku IP. Na końcu znajduje się oryginalny datagram (zarówno nagłówek IP, jak i pierwotne dane właściwe). Protokół AH uwierzytelnia cały datagram, co oznacza, że zdalny system może wykryć, czy datagram został zmieniony podczas przesyłania.
Jeśli jeden z punktów końcowych Security Association jest bramą, należy korzystać z trybu tunelowego. W trybie tym adresy źródłowy i docelowy w zewnętrznym nagłówku IP nie muszą być takie same, jak w oryginalnym nagłówku IP. Na przykład na dwóch bramach bezpieczeństwa może działać tunel AH służący do uwierzytelniania całego ruchu między połączonymi sieciami. W rzeczywistości jest to bardzo typowa konfiguracja.
Główną zaletą trybu tunelowego jest to, że całkowicie chroni on zahermetyzowany datagram IP. Ponadto tryb tunelowy umożliwia wykorzystanie adresów prywatnych.
Dlaczego AH?
W wielu przypadkach dane wymagają tylko uwierzytelnienia. Chociaż protokół Encapsulating Security Payload (ESP) również może uwierzytelniać dane, jego zastosowanie znacznie wyraźniej odbija się na wydajności systemu niż zastosowanie protokołu AH. Inną zaletą protokołu AH jest to, że uwierzytelnia on cały datagram. Jednakże protokół ESP nie uwierzytelnia zewnętrznego nagłówka IP ani żadnych innych danych, które występują przed nagłówkiem ESP.
Ponadto wdrożenie protokołu ESP wymaga silnych kluczy szyfrujących. Użycie takich kluczy jest w niektórych krajach ograniczone obowiązującymi przepisami; ograniczeniom tym nie podlega protokół AH i może być swobodnie stosowany na całym świecie.
Używanie numeru ESN razem z protokołem AH
Jeśli wykorzystywany jest protokół AH, to może okazać się konieczne aktywowanie numeru ESN. Umożliwia on przesyłanie dużych woluminów danych przy dużej szybkości bez ponownego szyfrowania za pomocą klucza. Połączenie VPN korzysta z 64-bitowych numerów kolejnych zamiast 32-bitowych numerów w IPSec. Używanie 64-bitowych numerów kolejnych wydłuża czas do wymiany klucza, co przeciwdziała wyczerpaniu numerów kolejnych i minimalizuje użycie zasobów systemowych.
Jakich algorytmów używa protokół AH do ochrony informacji?
Protokół AH
wykorzystuje algorytmy zwane kodami HMAC. W przypadku sieci VPN używane są konkretnie algorytmy HMAC-MD5, HMAC-SHA, HMAC-SHA-256, 
HMAC-SHA384, HMAC-SHA512 
lub AES-XCBC-MAC. Algorytmy te przetwarzają dane o zmiennej długości oraz klucz tajny w dane
wyjściowe o stałej długości (zwane wartością mieszającą lub wartością MAC). Jeśli wartości mieszające obydwu wiadomości są zgodne, jest prawdopodobne, że
wiadomości te są takie same.
Formalna definicja tych algorytmów została opublikowana przez grupę wykonawczą IETF (Internet Engineering Task Force) w następujących dokumentach RFC (Request for Comments):
- HMAC-MD5: w dokumencie RFC 2085, HMAC-MD5 IP Authentication with Replay Prevention.
- HMAC-SHA: w dokumencie RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH.
- HMAC-SHA-256 , HMAC-SHA-384 i HMAC-SHA-512 w dokumencie RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
- AES-XCBC-MAC: w dokumencie RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec.
Dokumenty te są dostępne w serwisie WWW pod adresem http://www.rfc-editor.org.
