Zum Hauptinhalt springen

3.3. SA-Payload

3.3. SA-Payload​

Das in diesem Dokument als SA bezeichnete Security Association (Sicherheitszuordnung) Payload dient der Aushandlung der Attribute einer Sicherheitszuordnung. Das Zusammenstellen eines SA-Payloads erfordert äußerste Sorgfalt. Ein SA-Payload kann mehrere Vorschläge (Proposals) enthalten. Falls mehrere Vorschläge vorhanden sind, MÜSSEN sie in der Reihenfolge vom bevorzugten zum weniger bevorzugten angeordnet sein. Jeder Vorschlag enthält ein einzelnes IPsec-Protokoll (das Protokoll kann IKE, ESP oder AH sein), und jedes Protokoll kann mehrere Transformationen (Transforms) enthalten, von denen jede wiederum mehrere Attribute enthalten kann. Beim Parsen eines SA MUSS die Implementierung prüfen, ob die gesamte Payload Length mit der Summe der Längen und Zähler innerhalb dieses Payloads übereinstimmt. Vorschläge, Transformationen und Attribute haben jeweils eine kodierte Variable-Length-Darstellung. Sie sind verschachtelt angeordnet, sodass die SA Payload Length den zusammengeführten Inhalt von SA, Vorschlag, Transformation und Attributinformationen umfasst. Die Länge eines Vorschlags umfasst die Längen aller darin enthaltenen Transformationen und Attribute. Die Länge einer Transformation umfasst die Längen aller darin enthaltenen Attribute.

Die Syntax von Security Association, Vorschlag, Transformation und Attribut basiert auf ISAKMP; ihre Semantik weicht jedoch ab. Der Grund für diese Komplexität und Hierarchie besteht darin, dass die Kodierung mehrerer möglicher Algorithmuskombinationen in einem einzigen SA ermöglicht werden soll. Manchmal muss zwischen mehreren Algorithmen gewählt werden, manchmal handelt es sich um Kombinationen von Algorithmen. Beispielsweise möchte der Initiator möglicherweise ESP zusammen mit (3DES und HMAC_MD5) oder (AES und HMAC_SHA1) vorschlagen.

Einer der Gründe, warum sich die Semantik des SA-Payloads im Vergleich zu ISAKMP und IKEv1 geändert hat, besteht darin, die Kodierung für häufige Fälle kompakter zu gestalten.

Die Vorschlagsstruktur enthält eine Proposal-Nummer und eine IPsec-Protokoll-ID. Jede Struktur MUSS eine um 1 höhere Nummer als die vorherige Struktur aufweisen. Der erste Vorschlag im SA-Payload des Initiators MUSS die Proposal-Nummer 1 (Eins) haben. Einer der Gründe für die Verwendung mehrerer Vorschläge besteht darin, gleichzeitig Standardverschlüsselungsalgorithmen und kombinierte Modi (combined-mode) vorzuschlagen. Ein kombinierter Modus-Algorithmus kapselt Integrität und Verschlüsselung in einem einzigen Verschlüsselungsalgorithmus und MUSS entweder keinen Integritätsalgorithmus bereitstellen oder einen einzelnen „none“-Integritätsalgorithmus angeben, wobei das Nichtbereitstellen des Integritätsalgorithmus die EMPFOHLENE Methode ist. Wenn der Initiator gleichzeitig kombinierte Modi und normale Algorithmen vorschlagen möchte, MUSS er zwei Vorschläge enthalten: einen mit allen kombinierten Modi-Algorithmen und einen mit allen normalen Algorithmen samt Integritätsalgorithmen. Beispielsweise hätte ein solcher Vorschlag zwei Vorschlagsstrukturen. Vorschlag 1 ist ESP mit AES-128, AES-192 und AES-256 im CBC-Modus, wobei der Integritätsalgorithmus HMAC-SHA1-96 oder XCBC-96 ist; Vorschlag 2 ist AES-128 oder AES-256 im GCM-Modus mit einem 8 Byte großen Integrity Check Value (ICV). Beide Vorschläge erlauben, aber verlangen nicht, die Verwendung von ESN (Extended Sequence Number). Dies lässt sich wie folgt darstellen:

SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | | 7 transforms, SPI = 0x052357bb ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | | | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) | +-- Transform ESN ( Name = ESNs ) | +-- Transform ESN ( Name = No ESNs ) | +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, | 4 transforms, SPI = 0x35a1d6f2 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 256 ) | +-- Transform ESN ( Name = ESNs ) +-- Transform ESN ( Name = No ESNs )

Auf jeden Vorschlag/Protokoll-Struktur folgen eine oder mehrere Transformationsstrukturen. Die Anzahl der unterschiedlichen Transformationen wird im Allgemeinen durch das Protokoll bestimmt. AH hat im Allgemeinen zwei Transformationen: Extended Sequence Number (ESN) und einen Integritätsprüfalgorithmus. ESP hat im Allgemeinen drei: ESN, einen Verschlüsselungsalgorithmus und einen Integritätsprüfalgorithmus. IKE hat im Allgemeinen vier: eine Diffie-Hellman-Gruppe, einen Integritätsprüfalgorithmus, einen PRF-Algorithmus und einen Verschlüsselungsalgorithmus. Für jedes Protokoll wird die zulässige Menge an Transformationen mit Transform-ID-Nummern versehen, die im Kopf jeder Transformation erscheinen.

Wenn es mehrere Transformationen desselben Transform-Typs gibt, handelt es sich bei dem Vorschlag um ein „Oder“ (OR) dieser Transformationen. Wenn es mehrere Transformationen unterschiedlichen Transform-Typs gibt, handelt es sich um ein „Und“ (AND) zwischen den verschiedenen Gruppen. Beispielsweise würde man, um ESP zusammen mit (3DES oder AES-CBC) und (HMAC_MD5 oder HMAC_SHA) vorzuschlagen, im ESP-Vorschlag zwei Transform-Typ-1-Kandidaten (einen für 3DES, einen für AEC-CBC) sowie zwei Transform-Typ-3-Kandidaten (einen für HMAC_MD5, einen für HMAC_SHA) aufnehmen. Dies schlägt effektiv vier Algorithmuskombinationen vor. Wenn der Initiator nur eine Teilmenge dieser Kombinationen vorschlagen möchte, etwa (3DES und HMAC_MD5) oder (IDEA und HMAC_SHA), lässt sich dies nicht als mehrere Transformationen innerhalb eines einzigen Vorschlags kodieren. Stattdessen MUSS der Initiator zwei verschiedene Vorschläge erstellen, von denen jeder zwei Transformationen enthält.

Eine bestimmte Transformation KANN ein oder mehrere Attribute aufweisen. Attribute sind notwendig, wenn eine Transformation auf unterschiedliche Weise verwendet werden kann (beispielsweise ein Verschlüsselungsalgorithmus mit variabler Schlüssellänge). Die Transformation gibt den Algorithmus an, das Attribut die Schlüssellänge. Die meisten Transformationen haben keine Attribute. Eine Transformation DARF NICHT mehrere Attribute desselben Typs aufweisen. Um Alternativwerte für ein Attribut vorzuschlagen (beispielsweise mehrere Schlüssellängen für den AES-Verschlüsselungsalgorithmus), MUSS die Implementierung mehrere Transformationen desselben Transform-Typs mit jeweils einem separaten Attribut aufnehmen.

Beachten Sie, dass die Semantik von Transformationen und Attributen stark von der in IKEv1 abweicht. In IKEv1 trug eine einzelne Transformation mehrere Algorithmen für ein Protokoll, von denen einer in der Transformation und die übrigen in Attributen transportiert wurden.

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6:  Format des SA-Payloads

o Proposals (variable Länge) – eine oder mehrere Vorschlags-Substrukturen.

Der Payload-Typ des SA-Payloads ist dreiunddreißig (33).

3.3.1. Vorschlags-Substruktur​

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7:  Vorschlags-Substruktur

o 0 (letzter) oder 2 (mehr) (1 Byte) – gibt an, ob dies die letzte Vorschlags-Substruktur im SA ist. Diese Syntax wurde von ISAKMP übernommen, ist jedoch nicht notwendig, da der letzte Vorschlag aus der Länge des SA erkennbar ist. Der Wert (2) entspricht dem Payload-Typ des Proposals in IKEv1, und die ersten vier Bytes der Vorschlagsstruktur wurden ähnlich wie der Kopf eines Payloads gestaltet.

o RESERVED (1 Byte) – MUSS als 0 gesendet werden; beim Empfang MUSS ignoriert werden.

o Proposal Length (2 Byte, vorzeichenlose Ganzzahl) – die Länge dieses Vorschlags, einschließlich aller folgenden Transformationen und Attribute.

o Proposal Num (1 Byte) – beim Vorschlagen MUSS der erste Vorschlag im SA-Payload 1 sein, und nachfolgende Vorschläge MÜSSEN um 1 größer als der vorherige Vorschlag sein (dies drückt eine „Oder“-Beziehung zwischen zwei Vorschlägen aus). Wenn ein Vorschlag akzeptiert wird, MUSS die Vorschlagsnummer im SA-Payload mit der Nummer des gesendeten akzeptierten Vorschlags übereinstimmen.

o Protocol ID (1 Byte) – gibt den ausgehandelten IPsec-Protokollbezeichner an. Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Protocol Protocol ID​

IKE 1 AH 2 ESP 3

o SPI Size (1 Byte) – für die anfängliche IKE-SA-Aushandlung MUSS dieses Feld 0 sein; die SPI wird aus dem äußeren Kopf ermittelt. Während späterer Aushandlungen entspricht es der SPI-Größe (in Byte) des entsprechenden Protokolls (IKE: 8, ESP und AH: 4).

o Num Transforms (1 Byte) – gibt die Anzahl der Transformationen in diesem Vorschlag an.

o SPI (variable Länge) – die SPI der sendenden Entität. Selbst wenn das Feld SPI Size keine ganzzahlige Vielfache von 4 Byte ist, wird dem Payload keine Auffüllung (Padding) hinzugefügt. Wenn das Feld SPI Size 0 ist, erscheint dieses Feld nicht im Security Association Payload.

o Transforms (variable Länge) – eine oder mehrere Transformations-Substrukturen.

3.3.2. Transformations-Substruktur​

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8:  Transformations-Substruktur

o 0 (letzter) oder 3 (mehr) (1 Byte) – gibt an, ob dies die letzte Transformations-Substruktur im Vorschlag ist. Diese Syntax wurde von ISAKMP übernommen, ist jedoch nicht notwendig, da die letzte Transformation aus der Länge des Vorschlags erkennbar ist. Der Wert (3) entspricht dem Payload-Typ der Transformation in IKEv1, und die ersten vier Bytes der Transformationsstruktur wurden ähnlich wie der Kopf eines Payloads gestaltet.

o RESERVED – MUSS als 0 gesendet werden; beim Empfang MUSS ignoriert werden.

o Transform Length – die Länge der Transformations-Substruktur (in Byte), einschließlich Kopf und Attributen.

o Transform Type (1 Byte) – der im Vorschlag angegebene Transform-Typ. Verschiedene Protokolle unterstützen unterschiedliche Transform-Typen. Für einige Protokolle können einige Transformationen optional sein. Wenn eine Transformation optional ist und der Initiator diese Transformation weglassen möchte, nimmt er keinen Transform dieses Typs in den Vorschlag auf. Wenn der Initiator möchte, dass die Transformation für den Responder optional ist, nimmt er eine Transformations-Substruktur auf, die einen Transform mit der Transform-ID = 0 als eine der Optionen enthält.

o Transform ID (2 Byte) – die konkrete Instanz des vorgeschlagenen Transform-Typs.

Die Werte des Transform-Typs sind in der folgenden Tabelle aufgeführt. Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Description Trans. Used In Type​

Encryption Algorithm (ENCR) 1 IKE and ESP Pseudorandom Function (PRF) 2 IKE Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP Extended Sequence Numbers (ESN) 5 AH and ESP

(*) Im Hinblick auf das in diesem Dokument festgelegte Verschlüsselungs-Payload-Format ist die Aushandlung eines Integritätsalgorithmus obligatorisch. Beispielsweise legt [AEAD] ein zusätzliches Format auf Basis von authenticated encryption fest, bei dem kein separater Integritätsalgorithmus ausgehandelt wird.

Für Transform-Typ 1 (Verschlüsselungsalgorithmus) ist die Transform-ID in der folgenden Tabelle aufgeführt. Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Name Number Defined In​

ENCR_DES_IV64 1 (UNSPECIFIED) ENCR_DES 2 (RFC2405), [DES] ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CTR 13 (RFC3686)

Für Transform-Typ 2 (Pseudozufallsfunktion) ist die Transform-ID in der folgenden Tabelle aufgeführt. Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Name Number Defined In​

PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_TIGER 3 (UNSPECIFIED)

Für Transform-Typ 3 (Integritätsalgorithmus) sind die definierten Transform-IDs in der folgenden Tabelle aufgeführt. Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Name Number Defined In​

NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_AES_XCBC_96 5 (RFC3566)

Für Transform-Typ 4 (Diffie-Hellman-Gruppe) sind die definierten Transform-IDs in der folgenden Tabelle aufgeführt. Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Name Number Defined In​

NONE 0 768-bit MODP 1 Appendix B 1024-bit MODP 2 Appendix B 1536-bit MODP 5 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP]

Obwohl ESP und AH keinen direkten Diffie-Hellman-Austausch enthalten, KANN für eine Child-SA eine Diffie-Hellman-Gruppe ausgehandelt werden. Dies erlaubt dem Peer, in einem CREATE_CHILD_SA-Austausch Diffie-Hellman zu verwenden und so Perfect Forward Secrecy für die generierten Child-SA-Schlüssel bereitzustellen.

Für Transform-Typ 5 (erweiterte Sequenznummern) sind die definierten Transform-IDs in der folgenden Tabelle aufgeführt. Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Name Number​

No Extended Sequence Numbers 0 Extended Sequence Numbers 1

Beachten Sie, dass ein Initiator, der ESN unterstützt, normalerweise zwei ESN-Transformationen in seinem Vorschlag aufnimmt, mit den Werten „0“ und „1“. Ein Vorschlag, der eine einzelne ESN-Transformation mit dem Wert „1“ enthält, bedeutet, dass die Verwendung normaler (nicht erweiterter) Sequenznummern nicht akzeptabel ist.

Seit der Veröffentlichung von RFC 4306 wurden zahlreiche zusätzliche Transform-Typen definiert. Einzelheiten finden sich in der IANA-IKEv2-Registry.

3.3.3. Gültige Transform-Typen je Protokoll​

Die Anzahl und Art der Transformationen, die einen SA-Payload begleiten, hängt von dem Protokoll ab, in dem sich der SA selbst befindet. Ein Vorschlag, der einen SA erstellt, hat die folgenden obligatorischen und optionalen Transform-Typen. Eine konforme Implementierung MUSS alle obligatorischen und optionalen Typen (auch wenn sie einen Vorschlag mit inakzeptablem Satz nicht akzeptieren muss) für jedes Protokoll verstehen, das sie unterstützt. Wenn der einzige akzeptable Wert für sie bei einem optionalen Typ NONE ist, KANN der Vorschlag diesen optionalen Typ weglassen.

Protocol Mandatory Types Optional Types​

IKE ENCR, PRF, INTEG*, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H

(*) Im Hinblick auf das in diesem Dokument festgelegte Verschlüsselungs-Payload-Format ist die Aushandlung eines Integritätsalgorithmus obligatorisch. Beispielsweise legt [AEAD] ein zusätzliches Format auf Basis von authenticated encryption fest, bei dem kein separater Integritätsalgorithmus ausgehandelt wird.

3.3.4. Obligatorische Transform-IDs​

Die in diesem Dokument festgelegten, für die Interoperabilität zwingend zu unterstützenden und zu empfehlenden Suiten wurden entfernt, da sie sich möglicherweise schneller ändern als dieses Dokument weiterentwickelt wird. Zum Zeitpunkt der Veröffentlichung dieses Dokuments legt [RFC4307] diese Suiten fest; beachten Sie jedoch, dass es in Zukunft aktualisiert werden könnte und dass andere RFCs andere Suitensammlungen festlegen könnten.

Eine wichtige Lektion aus IKEv1 lautet: Kein System sollte nur die obligatorischen Algorithmen implementieren und erwarten, dass diese die beste Wahl für alle Kunden sind.

Es ist sehr wahrscheinlich, dass IANA in Zukunft zusätzliche Transformationen hinzufügt und dass einige Benutzer private Suiten (insbesondere für IKE) verwenden möchten. Implementierungen SOLLTEN in der Lage sein, unterschiedliche Parameter bis zu einer bestimmten Größenbegrenzung zu unterstützen. Um dieses Ziel zu unterstützen, SOLLTEN alle IKEv2-Implementierungen eine Verwaltungseinrichtung enthalten, die es (dem Benutzer oder Systemadministrator) erlaubt, die Diffie-Hellman-Parameter (Generator, Modulus sowie Exponentenlänge und -wert) für eine neue Diffie-Hellman-Gruppe anzugeben. Implementierungen SOLLTEN eine Verwaltungsschnittstelle bereitstellen, über die diese Parameter zusammen mit der zugehörigen Transform-ID eingegeben werden können, um die Aushandlung solcher Gruppen zu ermöglichen.

Alle IKEv2-Implementierungen MÜSSEN eine Verwaltungseinrichtung enthalten, die es dem Benutzer oder Systemadministrator erlaubt, die mit IKE verwendbaren akzeptablen Suiten festzulegen. Beim Empfang eines Payloads mit einer Transform-ID-Menge MUSS die Implementierung die übertragenen Transform-IDs mit den über die Verwaltungssteuerung lokal konfigurierten Transform-IDs vergleichen, um die vorgeschlagene Suite gemäß der lokalen Richtlinie auf Akzeptabilität zu prüfen. Implementierungen MÜSSEN solche SA-Vorschläge ablehnen, die nicht von diesen IKE-Suiten-Steuerungen autorisiert sind. Beachten Sie, dass die Implementierung von Verschlüsselungssuiten nicht zwingend bedeutet, dass diese für die lokale Richtlinie akzeptabel konfiguriert sind.

3.3.5. Transform-Attribute​

Jede Transformation in einem Security Association Payload KANN Attribute enthalten, die die Transformationsspezifikation modifizieren oder verfeinern. Die Menge gültiger Attribute hängt von der Transformation ab. Derzeit wird nur ein einziger Attributtyp verwendet: das Schlüssellängen-Attribut (Key Length) wird von einigen Verschlüsselungstransformationen mit variabler Schlüssellänge verwendet (siehe unten).

Attribute sind Typ/Wert-Paare und werden wie folgt definiert. Ein Attribut kann einen festen, zwei Byte langen Wert haben oder einen Wert variabler Länge. Im letzteren Fall wird das Attribut als Typ/Länge/Wert (TLV) kodiert.

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Attribute Type | AF=0 Attribute Length | |F| | AF=1 Attribute Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AF=0 Attribute Value | | AF=1 Not Transmitted | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 9:  Datenattribut

o Attribute Format (AF) (1 Bit) – gibt an, ob das Datenattribut dem Typ/Länge/Wert (TLV)-Format oder dem verkürzten Typ/Wert (TV)-Format folgt. Wenn das AF-Bit null (0) ist, verwendet das Attribut das TLV-Format; wenn das AF-Bit eins (1) ist, wird das TV-Format (mit einem zwei Byte großen Wert) verwendet.

o Attribute Type (15 Bit) – ein eindeutiger Bezeichner für jeden Attributtyp (siehe unten).

o Attribute Value (variable Länge) – der mit dem Attributtyp verknüpfte Attributwert. Wenn das AF-Bit null (0) ist, hat dieses Feld die durch das Feld Attribute Length definierte variable Länge; wenn das AF-Bit eins (1) ist, beträgt die Länge des Attributwerts 2 Byte.

Der derzeit einzig definierte Attributtyp (Key Length) ist feste Länge; die Aufnahme einer variablen Längenkodierung dient nur zukünftigen Erweiterungen. Attribute, die als feste Länge beschrieben werden, DÜRFEN NICHT mit variabler Länge kodiert werden, es sei denn, ihre Länge überschreitet zwei Byte. Variable Längenattribute MÜSSEN NICHT als feste Länge kodiert werden, selbst wenn ihr Wert in zwei Byte passt. Beachten Sie: Dies unterscheidet sich von IKEv1, wo die erhöhte Flexibilität das Schreiben von Nachrichten vereinfachen mochte, aber zweifellos die Parser verkomplizierte.

Die Werte in der folgenden Tabelle waren nur zum Zeitpunkt der Veröffentlichung von RFC 4306 gültig. Seitdem können weitere Werte hinzugefügt worden sein oder werden hinzugefügt. Leser sollten [IKEV2IANA] für die aktuellen Werte konsultieren.

Attribute Type Value Attribute Format​

Key Length (in bits) 14 TV

Die Werte 0–13 sowie 15–17 wurden im ähnlichen Kontext von IKEv1 verwendet und sollten nicht zugewiesen werden, sofern nicht für übereinstimmende Werte.

Das Schlüssellängen-Attribut gibt die Schlüssellänge in Bits an (MUSS in Network-Byte-Reihenfolge verwendet werden) und gilt für einige Transformationen wie folgt:

o Das Schlüssellängen-Attribut DARF NICHT für Transformationen mit festlängigen Schlüsseln verwendet werden. Dies schließt ENCR_DES, ENCR_IDEA sowie alle in diesem Dokument festgelegten Transformationen des Typs 2 (Pseudozufallsfunktion) und Typs 3 (Integritätsalgorithmus) ein. Zukünftige Transformationen des Typs 2 oder 3 sollten dieses Attribut nicht verwenden.

o Einige Transformationen schreiben vor, dass das Schlüssellängen-Attribut immer enthalten sein MUSS (das Weglassen des Attributs ist nicht zulässig, und ein Vorschlag, der es nicht enthält, MUSS abgelehnt werden). Hierzu zählen beispielsweise ENCR_AES_CBC und ENCR_AES_CTR.

o Einige Transformationen erlauben variable Schlüssellängen, legen jedoch eine Standard-Schlüssellänge fest, falls das Attribut nicht enthalten ist. Hierzu zählen beispielsweise ENCR_RC5 und ENCR_BLOWFISH.

Implementierungshinweis: Um die Interoperabilität weiter zu verbessern und unabhängige Upgrades von Endpunkten zu unterstützen, SOLLTEN Implementierungen dieses Protokolls Werte akzeptieren, von denen sie glauben, dass sie ein höheres Maß an Sicherheit bieten. Wenn beispielsweise der Peer so konfiguriert ist, dass er eine Chiffre mit einer Schlüssellänge von X Bit akzeptiert, und ihm eine größere Schlüssellänge derselben Chiffre angeboten wird, SOLLTE die Implementierung den Vorschlag akzeptieren, sofern sie die Verwendung des längeren Schlüssels unterstützt.

Die Unterstützung dieser Fähigkeit erlaubt dem Responder, das Konzept eines „mindestens“ bestimmten Sicherheitsniveaus auszudrücken – „Chiffre Y mit einer Schlüssellänge von mindestens X Bit“. Da das Attribut jedoch immer unverändert zurückgegeben wird (siehe nächster Abschnitt), MUSS ein Initiator, der mehrere Schlüssellängen akzeptieren möchte, mehrere Transformationen desselben Transform-Typs mit jeweils einem unterschiedlichen Schlüssellängen-Attribut aufnehmen.

3.3.6. Attribut-Aushandlung​

Während der Aushandlung einer Security Association unterbreitet der Initiator dem Responder Vorschläge. Der Responder MUSS aus den Vorschlägen eine einzelne vollständige Parametersatz auswählen (oder alle Vorschläge ablehnen, falls kein akzeptabler vorhanden ist). Falls mehrere Vorschläge vorhanden sind, MUSS der Responder einen einzelnen Vorschlag auswählen. Wenn der ausgewählte Vorschlag mehrere Transformationen desselben Typs hat, MUSS der Responder eine einzelne Transformation auswählen. Alle Attribute einer ausgewählten Transformation MÜSSEN unverändert zurückgegeben werden. Der Initiator des Austauschs MUSS prüfen, ob der akzeptierte Vorschlag mit einem seiner Vorschläge übereinstimmt, und den Austausch abbrechen, falls nicht.

Wenn der Responder einen Vorschlag erhält, der einen Transform-Typ enthält, den er nicht versteht, oder einen Vorschlag ohne zwingend erforderlichen Transform-Typ, MUSS er den Vorschlag als inakzeptabel betrachten; andere Vorschläge im selben SA-Payload werden jedoch wie gewohnt verarbeitet. Entsprechend MUSS der Responder, wenn er eine Transformation erhält, die er nicht versteht, oder eine Transformation mit einem Transform-Attribut, das er nicht versteht, diese Transformation als inakzeptabel betrachten; andere Transformationen desselben Transform-Typs werden wie gewohnt verarbeitet. Dies erlaubt die zukünftige Definition neuer Transform-Typen und Transform-Attribute.

Die Aushandlung der Diffie-Hellman-Gruppe bringt einige besondere Herausforderungen mit sich. Der SA-Vorschlag enthält in derselben Nachricht die Attribute des Vorschlags und einen Diffie-Hellman-Öffentlichen Wert (KE). Wenn der Initiator im anfänglichen Austausch vorschlägt, eine von mehreren Diffie-Hellman-Gruppen zu verwenden, SOLLTE er diejenige auswählen, die vom Responder aller Voraussicht nach akzeptiert wird, und den entsprechenden KE-Wert einschließen. Wenn der Responder einen Vorschlag auswählt, der eine andere Diffie-Hellman-Gruppe (außer NONE) verwendet, gibt er in seiner Antwort die korrekte Gruppe an, und der Initiator SOLLTE bei der Wiederholung der ersten Nachricht ein Element dieser Gruppe als seinen KE-Wert wählen. Er SOLLTE jedoch weiterhin sein vollständig unterstütztes Gruppenspektrum vorschlagen, um Man-in-the-Middle-Degradationsangriffe zu verhindern. Wenn eine der vorgeschlagenen Gruppen die Diffie-Hellman-Gruppe NONE ist und der Responder diese Diffie-Hellman-Gruppe auswählt, MUSS er den KE-Payload des Initiators ignorieren und den KE-Payload aus seiner Antwort weglassen.