Rechnernetze

IP Authentication Header

Der IP Authentication Header (AH) bietet Authentifizierung für Daten und IP-Header, und kann in IPv4 und IPv6 verwendet werden. AH unterstützt neben dem Transport- auch den Tunnelmodus.

Der AH-Header wird hinter dem IP-Header und vor dem Header der oberen Transportschicht bzw. im Tunnelmodus vor dem inneren IP-Header eingefügt, im folgenden als Datenblock bezeichnet.

AH bietet Integrität bei verbindungsloser Kommunikation sowie Schutz vor Replay von Daten.

Paketformat des IP Authentication Header

AH-Pakete werden durch den Wert 51 im Nextheader-Feld des vorhergehenden Pakets gekennzeichnet. Das AH-Paket hat folgenden Aufbau:

Hierbei bedeuten die einzelnen Werte folgendes:

	Next Header Gibt den Typ der Payload-Daten an, z.B. Transportprotokoll oder einen Erweiterungsheader in IPv6. Dieser Wert kommt in jedem ESP-Header vor.
	Payload-Length Länge des AH in 32 Bit-Worten minus 2.
	RESERVED Hat den Wert null.
	Security Parameters Index (SPI) Ein 32 Bit-Wert, der in Kombination mit der Zieladresse und dem Protokoll AH eindeutig die SA für dieses Datagramm identifiziert. Gewisse Werte (1..255) dürfen in der Regel nicht vergeben werden, bzw. werden nur lokal (0) verwendet. Der Wert des SPI wird von dem Zielrechner beim Aufbau der SA festgelegt. Dieser Wert kommt in jedem AH-Paket vor.
	Sequenznummer Ein 32 Bit-Wert, der als Antireplay-Wert benutzt werden kann. Der Sender muss diesen Wert einfügen und beginnend bei 1 inkrementieren; der Empfänger kann diesen Wert auswerten, braucht es aber nicht. Der Wert darf nicht über den Höchstwert 2³²-1 inkrementiert werden, wenn es vom Empfänger ausgewertet wird. Dieser Wert kommt in jedem AH-Paket vor.
	Authentication Data Dient der Authentisierung des gesamten Pakets. Die Länge ist abhängig von dem Authentifizierungsalgorithmus. Dieser Wert ist optional.

Anordnung des IP-AH

Im Transportmodus wird ein AH nach dem IP-Header und vor den entsprechenden Daten der oberen Schichten, z.B. TCP oder auch ICMP, angeordnet. Das folgende Beispiel zeigt die Einkapselung eines TCP-Pakets in einem IPv4-Feld.

Das folgende Beispiel zeigt die Einkapselung eines TCP-Pakets in einem IPv6-Feld.

Im Tunnelmodus enthält der innere Header die Zieladressen, während der äußere IP-Header eine andere Adresse enthalten kann, z.B. die eines Security-Gateways. Für typische IPv4- und IPv6-Datagramme erhält man die folgende Anordnung des AH im Tunnelmodus:

Funktionen beim Senden eines AH-Pakets

Punkt-zu-Punkt-Kommunikation kann mit Hilfe eines schlüsselbasierten Message Authentication Codes wie DES oder mit Hashfunktionen wie MD5 oder SHA-1 authentisiert werden; die letzten beiden Algorithmen müssen implementiert sein.

Nachdem ein ausgehendes Paket aufgrund eines entsprechenden Eintrags in der Security Policy Database als AH-Paket erkannt wurde, wird zunächst das entsprechende Paket mit eingefügten AH konstruiert. Als Sequenznummer wird der jeweils nächste Wert genommen.

Bei IPv4 können mehrere Felder während der Übertragung verändert werden, z.B. Time to Live, Header Checksum oder bestimmte Optionen. Ebenso können bei IPv6 einige Felder beim Empfänger anders aussehen als beim Sender, z.B. das Feld Class, Flow Label oder Hop Limit. Einige andere Felder sind bei Sender und Empfänger vorhersehbar, wenngleich sie geändert werden können. Letztere enthalten in der Regel ihren vorhersehbaren Wert, die anderen veränderbaren Felder den Wert null.

Gegebenenfalls müssen die Authentisierungsdaten auf eine geeignete Länge gebracht werden, z.B. ein Vielfaches von 32 Bits in IPv4. Dieses wird durch ein entsprechendes Paddingfeld gemacht, wobei dessen beliebig ist.

Über das gesamte derart vorbereitete Paket wird der Integrity Check Value mit dem jeweiligen Authentifizierungsverfahren berechnet und in das Feld Authentisierungsdaten eingefügt. Gegebenenfalls können diese Pakete fragmentiert werden, müssen jedoch beim Empfänger vor der Prüfung wieder reassembliert werden.

Funktionen beim Empfangen eines AH-Pakets

Nachdem ein eingehendes Paket aufgrund eines entsprechenden Eintrags in der Security Policy Database als AH-Paket erkannt wurde, wird zunächst das Sequenznummernfeld überprüft, wenn die SA das vorschreibt. Da eingehende Pakete in beliebiger Reihenfolge eintreffen können, wird ein Fensterverfahren vorgeschlagen, welches 32 bis 64 Sequenznummer verifiziert und auf Duplikate überprüft. Wird ein dupliziertes Paket erkannt, so wird dieses in einer Logdatei protokolliert.

Als nächstes wird Authentisierung durchgeführt, indem in dem AH-Paket die Authentisierungsdaten gespeichert und dann das Feld Authentication Data auf null gesetzt wird, einschließlich aller veränderbaren Felder. Felder, deren Werte geändert wurden aber vorhersehbar sind werden mit diesem Wert belegt. Danach kann der vereinbarte Algorithmus angewendet und das Ergebnis mit den Authentisierungsdaten abgeglichen werden. Ein Fehler wird in einer Logdatei unter Angabe von SPI, Empfangszeit, Quell- und Zieladresse und Sequenznummer protokolliert.

Der Standard nennt zu protokollierende Fehler auditable events, die in der Regel in einer Logdatei protokolliert werden. Es wird nicht verlangt, dass jedes System Fehler protokolliert, jedoch wenn es dieses durchführt, so müssen die Mechanismen zum Protokollieren von AH-Fehlern vorgesehen werden und der Administrator muss dieses ein- bzw. ausschalten können. Im Falle eines derartigen Fehlers ist der Empfänger nicht verpflichtet, diesen an den Absender zu melden, um auf diese Weise beispielsweise die Gefahr von Denial-of-Service-Angriffen zu verhindern.