Zum Hauptinhalt springen

3.2. Algorithms (Algorithmen)

3.2. Algorithms (Algorithmen)

Die verpflichtend zu implementierenden Algorithmen für die Verwendung mit ESP werden in einem separaten RFC beschrieben, um die Aktualisierung der Algorithmenanforderungen unabhängig vom Protokoll selbst zu erleichtern. Zusätzliche Algorithmen, die über die für ESP vorgeschriebenen hinausgehen, KÖNNEN unterstützt werden. Beachten Sie, dass obwohl sowohl Vertraulichkeit als auch Integrität optional sind, mindestens einer dieser Dienste ausgewählt werden MUSS, daher DÜRFEN beide Algorithmen NICHT gleichzeitig NULL sein.

3.2.1. Encryption Algorithms (Verschlüsselungsalgorithmen)

Der zur Schutz eines ESP-Pakets verwendete Verschlüsselungsalgorithmus wird durch die SA spezifiziert, über die das Paket übertragen/empfangen wird. Da IP-Pakete in falscher Reihenfolge ankommen können und nicht alle Pakete ankommen können (Paketverlust), muss jedes Paket alle Daten tragen, die erforderlich sind, um dem Empfänger die Herstellung der kryptografischen Synchronisation für die Entschlüsselung zu ermöglichen. Diese Daten können explizit im Payload-Feld getragen werden, z.B. als IV (wie oben beschrieben), oder die Daten können aus den Klartextteilen des (äußeren IP- oder ESP-) Paketheaders abgeleitet werden. (Beachten Sie, dass wenn Klartext-Header-Informationen zur Ableitung eines IV verwendet werden, diese Informationen sicherheitskritisch werden können und somit die mit dem Verschlüsselungsprozess verbundene Schutzgrenze wachsen kann. Wenn man beispielsweise die ESP-Sequenznummer zur Ableitung eines IV verwenden würde, müsste die Sequenznummer-Generierungslogik (Hardware oder Software) als Teil der Verschlüsselungsalgorithmus-Implementierung bewertet werden. Im Fall von FIPS 140-2 [NIST01] könnte dies den Umfang einer Kryptomodul-Bewertung erheblich erweitern.) Da ESP Vorkehrungen für das Auffüllen des Klartexts trifft, können mit ESP verwendete Verschlüsselungsalgorithmen entweder Block- oder Strommodus-Eigenschaften aufweisen. Beachten Sie, dass da Verschlüsselung (Vertraulichkeit) ein optionaler Dienst sein KANN (z.B. reine Integritäts-ESP), dieser Algorithmus "NULL" [Ken-Arch] sein KANN.

Um einer ESP-Implementierung die Berechnung des von einem Blockmode-Verschlüsselungsalgorithmus erforderlichen Verschlüsselungs-Paddings zu ermöglichen und die MTU-Auswirkung des Algorithmus zu bestimmen, muss das RFC für jeden mit ESP verwendeten Verschlüsselungsalgorithmus den Padding-Modulus für den Algorithmus spezifizieren.

3.2.2. Integrity Algorithms (Integritätsalgorithmen)

Der für die ICV-Berechnung verwendete Integritätsalgorithmus wird durch die SA spezifiziert, über die das Paket übertragen/empfangen wird. Wie bei Verschlüsselungsalgorithmen muss jeder mit ESP verwendete Integritätsalgorithmus Vorkehrungen treffen, um die Verarbeitung von Paketen zu ermöglichen, die in falscher Reihenfolge ankommen, und um Paketverlust zu berücksichtigen. Die oben genannte Warnung gilt auch für die Verwendung von Klartextdaten zur Erleichterung der Empfängersynchronisation von Integritätsalgorithmen. Beachten Sie, dass da der Integritätsdienst optional sein KANN, dieser Algorithmus "NULL" sein kann.

Um einer ESP-Implementierung die Berechnung des erforderlichen impliziten Integritätsalgorithmus-Paddings zu ermöglichen, muss das RFC für jeden mit ESP verwendeten Algorithmus den Padding-Modulus für den Algorithmus spezifizieren.

3.2.3. Combined Mode Algorithms (Kombinierte Modus-Algorithmen)

Wenn ein kombinierter Modus-Algorithmus verwendet wird, werden sowohl Vertraulichkeits- als auch Integritätsdienste bereitgestellt. Wie bei Verschlüsselungsalgorithmen muss ein kombinierter Modus-Algorithmus Vorkehrungen für die paketweise kryptografische Synchronisation treffen, um die Entschlüsselung von Paketen zu ermöglichen, die in falscher Reihenfolge ankommen, und um Paketverlust zu berücksichtigen. Die Art und Weise, wie ein kombinierter Modus-Algorithmus Integrität für die Payload und für die Felder SPI und (erweiterte) Sequenznummer bereitstellt, kann für verschiedene Algorithmus-Auswahlen variieren. Um einen einheitlichen, algorithmusunabhängigen Ansatz zur Aufrufung kombinierter Modus-Algorithmen bereitzustellen, ist keine Payload-Substruktur definiert. Beispielsweise könnten die Felder SPI und Sequenznummer innerhalb der Ciphertext-Hülle repliziert werden und ein ICV kann an den ESP-Trailer angehängt werden. Keines dieser Details sollte von außen beobachtbar sein.

Um einer ESP-Implementierung die Bestimmung der MTU-Auswirkung eines kombinierten Modus-Algorithmus zu ermöglichen, muss das RFC für jeden mit ESP verwendeten Algorithmus eine (einfache) Formel spezifizieren, die die verschlüsselte Payload-Größe als Funktion der Klartext-Payload- und Sequenznummer-Größen liefert.