Internetschlüsselaustausch (IKE oder IKEv2) ist das Protokoll, das verwendet ist, um eine Sicherheitsvereinigung (SA) im IPsec Protokoll-Gefolge aufzustellen. IKE baut laut des Protokolls von Oakley und ISAKMP. IKE verwendet X.509 Zertifikate für die Beglaubigung, die entweder vorgeteilt werden oder das Verwenden DNS (vorzugsweise mit DNSSEC), und ein Diffie-Hellman Schlüsselaustausch verteilt haben, um ein geteiltes Sitzungsgeheimnis aufzustellen, von dem kryptografische Schlüssel abgeleitet werden. Außerdem muss eine Sicherheitspolitik für jeden Gleichen, der in Verbindung stehen wird, manuell aufrechterhalten werden.

Geschichte

IKE wurde im November 1998 von Internet Engineering Task Force (IETF) in einer Reihe von Veröffentlichungen (Bitte um Anmerkungen) bekannt als RFC 2407, RFC 2408 und RFC 2409 ursprünglich definiert.

• RFC 2407 hat Das Internet IP Sicherheit Gebiet der Interpretation für ISAKMP definiert.
• RFC 2408 Internetsicherheit Vereinigung und Schlüsselverwaltungsprotokoll (ISAKMP)
• RFC 2409 hat Internet Key Exchange (IKE) definiert

IKE wurde zur Version zwei (IKEv2) im Dezember 2005 durch RFC 4306 aktualisiert. Einige offene Details wurden im Oktober 2006 durch RFC 4718 geklärt. Diese zwei Dokumente plus zusätzliche Erläuterungen wurden in den aktualisierten IKEv2 RFC 5996 verbunden, der im September 2010 veröffentlicht wurde.

Die Elternteilorganisation des IETF, Die Internetgesellschaft (Internet-Gesellschaft), hat die Copyrights dieser Standards als frei verfügbar seiend für die Internetgemeinschaft aufrechterhalten.

Architektur

Die meisten IPsec Durchführungen bestehen aus einem IKE Dämon, der im Benutzerraum und einem IPsec-Stapel im Kern läuft, der die wirklichen IP Pakete bearbeitet.

Benutzerraumdämonen haben leichten Zugang zur Massenlagerung, die Konfigurationsinformation, wie die IPsec Endpunkt-Adressen, Schlüssel und Zertifikate, wie erforderlich, enthält. Kernmodule können andererseits Pakete effizient und mit dem Minimum oben bearbeiten — der aus Leistungsgründen wichtig ist.

Das IKE Protokoll verwendet UDP Pakete, gewöhnlich auf dem Hafen 500, und verlangt allgemein, dass 4-6 Pakete mit 2-3 Umlaufzeiten einen SA an beiden Seiten schaffen. Das verhandelte Schlüsselmaterial wird dann dem IPsec-Stapel gegeben. Zum Beispiel konnte das ein AES Schlüssel, Information sein, die die IP Endpunkte und Häfen identifiziert, die geschützt werden sollen, sowie welcher IPsec Tunnel geschaffen worden ist. Der IPsec-Stapel fängt abwechselnd die relevanten IP Pakete ab, wenn und wo passend und Verschlüsselung/Dekodierung, wie erforderlich, durchführt. Durchführungen ändern sich darauf, wie das Auffangen der Pakete — zum Beispiel, einige virtuelle Gebrauch-Geräte getan wird, nehmen andere eine Scheibe aus der Brandmauer usw.

IKE Phases

IKE besteht aus zwei Phasen: Phase 1 und Phase 2.

IKE Zweck der Phase 1 ist, einen sicheren beglaubigten Nachrichtenkanal durch das Verwenden des Diffie-Hellman Schlüsselaustauschalgorithmus zu gründen, um einen geteilten heimlichen Schlüssel zu encrypt weiter IKE Kommunikationen zu erzeugen. Diese Verhandlung läuft auf eine einzelne bidirektionale ISAKMP Security Association (SA) hinaus. Die Beglaubigung kann mit jedem vorgeteiltem Schlüssel (geteiltes Geheimnis), Unterschriften oder öffentliche Schlüsselverschlüsselung durchgeführt werden. Phase 1 funktioniert entweder in der Hauptweise oder in Aggressiven Weise. Hauptweise schützt die Identität der Gleichen; aggressive Weise tut nicht.

Während der IKE Phase 2 verwenden die IKE-Gleichen den sicheren in der Phase 1 gegründeten Kanal, um Sicherheit Vereinigungen im Auftrag anderer Dienstleistungen wie IPsec zu verhandeln. Die Verhandlung läuft auf ein Minimum von zwei Einrichtungssicherheitsvereinigungen (ein inbound und ein auslaufender) hinaus. Phase 2 funktioniert nur in der Schnellen Weise.

Probleme mit IKE

Ursprünglich hatte IKE zahlreiche Konfigurationsoptionen, aber hat an einer allgemeinen Möglichkeit für die automatische Verhandlung eines wohl bekannten Verzug-Falls Mangel gehabt, der allgemein durchgeführt wird. Folglich mussten sich beide Seiten eines IKE über den Typ der Sicherheitsvereinigung genau einigen, die sie haben schaffen wollen — konnte die Auswahl durch die Auswahl — oder eine Verbindung nicht gegründet werden. Weitere Komplikationen sind aus der Tatsache entstanden, dass in vielen Durchführungen die Fehlersuchprogramm-Produktion schwierig war zu dolmetschen, wenn es Fehlersuchprogramm-Routine überhaupt gab.

Die IKE Spezifizierungen waren für einen bedeutenden Grad der Interpretation offen, an Designschulden (Tote gleichrangige Entdeckung grenzend, die ein typischer Fall ist), verschiedene IKE Durchführungsunfähigkeit verursachend, einen vereinbarten Sicherheitsvereinigung überhaupt für viele Kombinationen von Optionen zu schaffen, jedoch richtig hat konfiguriert sie könnten an jedem Ende erscheinen.

Verbesserungen mit IKEv2

Das Bedürfnis und die Absicht einer Überholung des IKE Protokolls wurden im Anhang A von RFC 4306 beschrieben. Die folgenden Probleme wurden gerichtet:

• Weniger RFCs: Die Spezifizierungen für IKE wurden in mindestens drei RFCs mehr bedeckt, wenn man NAT Traversal und andere Erweiterungen in Betracht zieht, die in der üblichen Anwendung sind. IKEv2 verbindet diese in einem RFC sowie bildenden Verbesserungen, um für das NAT Traversal und Brandmauer-Traversal im Allgemeinen zu unterstützen.
• Standardbeweglichkeitsunterstützung: Es gibt eine Standarderweiterung für IKEv2 (hat MOBIKE genannt) hat gepflegt, Beweglichkeit und multihoming dafür zu unterstützen, und BESONDERS Durch den Gebrauch dieser Erweiterung können IKEv2 und IPsec von beweglichen und multihomed Benutzern verwendet werden.
• NAT Traversal: Der encapsulation von IKE und BESONDERS im UDP Hafen 4500 ermöglicht diesen Protokollen, ein Gerät oder Brandmauer durchzuführen, die NAT durchführt.
• SCTP Unterstützung: IKEv2 berücksichtigt das SCTP Protokoll, wie verwendet, in der Internettelefonie VoIP.
• Einfacher Nachrichtenaustausch: IKEv2 hat einen anfänglichen Vier-Nachrichten-Austauschmechanismus, wo IKE acht ausgesprochen verschiedene anfängliche Austauschmechanismen zur Verfügung gestellt hat, von denen jeder im Vorteil und Nachteile gewesen ist.
• Weniger kryptografische Mechanismen: IKEv2 verwendet kryptografische Mechanismen, seine Pakete zu schützen, die was IPsec Gebrauch von Encapsulating Security Payload (ESP) sehr ähnlich sind, die IPsec Pakete zu schützen. Das hat zu einfacheren Durchführungen und Zertifikaten für Allgemeine Kriterien und FIPS 140-2 geführt, die verlangen, dass jede kryptografische Durchführung getrennt gültig gemacht wird.
• Zuverlässigkeit und Staatsmanagement: IKEv2 verwendet Folge-Zahlen und Anerkennungen, um Zuverlässigkeit zur Verfügung zu stellen, und beauftragt etwas Fehler, Logistik bearbeitend, und hat Zustandmanagement geteilt. IKE konnte in einem toten Staat wegen des Mangels an solchen Zuverlässigkeitsmaßnahmen enden, wo beide Parteien annahmen, dass der andere eine Handlung begonnen hat - der nie geendet hat. Arbeit arounds (wie Tote Gleichrangige Entdeckung) wurde entwickelt, aber nicht standardisiert. Das hat bedeutet, dass verschiedene Durchführungen des Arbeits-Arounds nicht immer vereinbar waren.
• Angriffselastizität von Denial of Service (DoS): IKEv2 führt viel Verarbeitung nicht durch, bis es bestimmt, ob der Antragsteller wirklich besteht. Das hat einige der DOS-Probleme gerichtet, die durch IKE ertragen sind, der viel teure kryptografische Verarbeitung von spoofed Positionen durchführen würde.

Das kann wie das erklärt werden:

Nehmen Sie an, dass HostA Security Parameter Index (SPI) A hat und HostB einen SPI B hat.

Das Drehbuch ist dem ähnlich:

HostA---------------HostB

Wenn HostB großen Betrag von halb offenem IKE init Verbindung erfährt, wird der Antwortsender eine Unencrypted-Antwort-Nachricht des ike_sa_init mit einer bekannt geben Nachricht des Typ-Plätzchens senden. Und der Antwortsender wird eine Ike_sa_init-Bitte mit diesem Plätzchen-Wert in einer bekannt geben Nutzlast erwarten. Das soll sicherstellen, dass der Initiator dazu wirklich fähig ist, eine Antwort vom Antwortsender zu behandeln.

HostA-------------------------------------------------HostB

HDR (A, 0)

,sai1,kei,Ni----------------------------->

Die ISAKMP/IKE Durchführung wurde von Cisco und Microsoft gemeinsam entwickelt.

Windows 7 von Microsoft und Windows-Server 2008 R2 unterstützen völlig IKEv2 (RFC 4306) sowie MOBIKE (RFC 4555) durch den VPN, Verbinden Eigenschaft (auch bekannt als Flinker VPN) Wieder.

Es gibt mehrere offene Quelldurchführungen von IPsec mit verbundenen IKE Fähigkeiten. Auf Linux stellen Openswan und strongSwan Durchführungen einem IKE Dämon genannt Pluto zur Verfügung, der konfigurieren kann (d. h., setzen Sie SAs ein) zum KLIPS oder NETKEY kernbasierte IPsec-Stapel. NETKEY ist Linux die IPsec heimische Durchführung von 2.6 Kern.

Der Softwarevertrieb von Berkeley hat auch eine IPsec Durchführung und IKE Dämon, und am wichtigsten ein kryptografisches Fachwerk (OpenBSD Kryptografisches Fachwerk, OCF), der unterstützende kryptografische Gaspedale viel leichter macht. OCF ist kürzlich zu Linux getragen worden.

Eine bedeutende Anzahl von Netzausrüstungsverkäufern hat ihre eigenen IKE Dämonen (und IPsec Durchführungen) geschaffen, oder lizenziert einen Stapel von einander.

Bezüglich des Mais 2006 gibt es mehrere Durchführungen von IKEv2, und einige der Gesellschaften, die sich im IPsec Zertifikat und der Zwischenfunktionsfähigkeitsprüfung befassen, fangen an, Werkstätten für die Prüfung sowie aktualisierten Zertifikat-Voraussetzungen zum Geschäft IKEv2 mit Prüfung zu halten. ICSA Laboratorien haben seine letzte IKEv2 Zwischenfunktionsfähigkeitswerkstatt in Orlando, Florida im März 2007 mit 13 Verkäufern von der ganzen Welt gehalten.

Die folgenden offenen Quelldurchführungen von IKEv2 sind zurzeit verfügbar:

• OpenIKEv2,
• strongSwan,
• Openswan,
• IKEv2,
• Waschbär und Racoon2 aus dem KAME-Projekt,
• iked aus dem Projekt von OpenBSD.

Siehe auch

• IPsec
• Schlüsselabmachungsprotokoll
• Gruppengebiet der Interpretation
• Kerberized Internetverhandlung von Schlüsseln

Links

• RFC 2407 Das Internet IP Sicherheit Gebiet der Interpretation für ISAKMP, Internet Engineering Task Force (IETF)
• RFC 2408 Internetsicherheit Vereinigung und Schlüsselverwaltungsprotokoll (ISAKMP), Internet Engineering Task Force (IETF)
• RFC 2409 Internet Key Exchange (IKE), Internet Engineering Task Force (IETF)
• RFC 5996: Internetschlüsselaustausch (IKEv2) Protokoll), Internet Engineering Task Force (IETF)
• Übersicht von IKE (von Cisco)