1. Introduction (Einführung)

Dieses Dokument geht davon aus, dass der Leser mit den Begriffen und Konzepten vertraut ist, die in der "Security Architecture for the Internet Protocol" [Ken-Arch] beschrieben werden, die im Folgenden als Security Architecture-Dokument bezeichnet wird. Insbesondere sollte der Leser mit den Definitionen der Sicherheitsdienste vertraut sein, die vom Encapsulating Security Payload (ESP) [Ken-ESP] und dem IP Authentication Header (IP-Authentifizierungsheader, AH) angeboten werden, dem Konzept der Security Associations (Sicherheitsassoziationen), den Möglichkeiten, wie ESP in Verbindung mit dem Authentication Header (AH) verwendet werden kann, und den verschiedenen verfügbaren Schlüsselverwaltungsoptionen für ESP und AH.

Die Schlüsselwörter MUST (MUSS), MUST NOT (DARF NICHT), REQUIRED (ERFORDERLICH), SHALL (MUSS), SHALL NOT (DARF NICHT), SHOULD (SOLLTE), SHOULD NOT (SOLLTE NICHT), RECOMMENDED (EMPFOHLEN), MAY (KANN) und OPTIONAL (OPTIONAL), wenn sie in diesem Dokument erscheinen, sind wie in RFC 2119 [Bra97] beschrieben zu interpretieren.

Der IP Authentication Header (AH) wird verwendet, um verbindungslose Integrität und Datenursprungsauthentifizierung für IP-Datagramme (im Folgenden nur als "Integrität" bezeichnet) bereitzustellen und Schutz gegen Wiederholungsangriffe (Replays) zu bieten. Dieser letztgenannte, optionale Dienst kann vom Empfänger ausgewählt werden, wenn eine Security Association (SA) eingerichtet wird. (Das Protokoll-Standardverhalten verlangt vom Sender, die für Anti-Replay verwendete Sequenznummer zu erhöhen, aber der Dienst ist nur wirksam, wenn der Empfänger die Sequenznummer überprüft.) Um jedoch die Extended Sequence Number-Funktion (erweiterte Sequenznummer) auf interoperable Weise zu nutzen, stellt AH eine Anforderung an SA-Verwaltungsprotokolle, diese neue Funktion aushandeln zu können (siehe Abschnitt 2.5.1 unten).

AH bietet Authentifizierung für so viel vom IP-Header wie möglich, sowie für Daten des nächsthöheren Protokolls. Einige IP-Header-Felder können sich jedoch während der Übertragung ändern, und der Wert dieser Felder, wenn das Paket beim Empfänger ankommt, kann vom Sender möglicherweise nicht vorhergesagt werden. Die Werte solcher Felder können nicht durch AH geschützt werden. Daher ist der von AH für den IP-Header bereitgestellte Schutz lückenhaft. (Siehe Anhang A.)

AH kann allein, in Kombination mit dem IP Encapsulating Security Payload (ESP) [Ken-ESP] oder in verschachtelter Weise angewendet werden (siehe Security Architecture-Dokument [Ken-Arch]). Sicherheitsdienste können zwischen einem Paar kommunizierender Hosts, zwischen einem Paar kommunizierender Security Gateways oder zwischen einem Security Gateway und einem Host bereitgestellt werden. ESP kann verwendet werden, um die gleichen Anti-Replay- und ähnliche Integritätsdienste bereitzustellen, und es bietet auch einen Vertraulichkeitsdienst (Verschlüsselung). Der Hauptunterschied zwischen der von ESP und AH bereitgestellten Integrität ist der Umfang der Abdeckung. Insbesondere schützt ESP keine IP-Header-Felder, es sei denn, diese Felder sind von ESP gekapselt (z.B. durch Verwendung des Tunnelmodus). Weitere Details zur Verwendung von AH und ESP in verschiedenen Netzwerkumgebungen finden Sie im Security Architecture-Dokument [Ken-Arch].

Abschnitt 7 bietet einen kurzen Überblick über die Unterschiede zwischen diesem Dokument und RFC 2402 [RFC2402].