Internetprotokoll-Sicherheit (IPsec) ist ein Protokoll-Gefolge, für Kommunikationen von Internet Protocol (IP) durch das Beglaubigen und encrypting jede einer Nachrichtensitzung zu sichern. IPsec schließt auch Protokolle ein, um gegenseitige Beglaubigung zwischen Agenten am Anfang der Sitzung und Verhandlung von kryptografischen Schlüsseln zu gründen, während der Sitzung verwendet zu werden.

IPsec ist der Länge nach Sicherheitsschema, das in der Internetschicht des Internetprotokoll-Gefolges funktioniert. Es kann im Schutz von Datenflüssen zwischen einem Paar von Gastgebern (Gastgeber-zu-Gastgeber), zwischen einem Paar von Sicherheitstoren (Netz-zu-Netz), oder zwischen einem Sicherheitstor und einem Gastgeber (Netz zum Gastgeber) verwendet werden.

Einige andere Internetsicherheitssysteme im weit verbreiteten Gebrauch, wie Secure Sockets Layer (SSL), Transport Layer Security (TLS) und Sicherer Shell (SSH), funktionieren in den oberen Schichten des TCP/IP Modells. In der Vergangenheit musste der Gebrauch von TLS/SSL in eine Anwendung entworfen werden, um die Anwendungsprotokolle zu schützen. Im Gegensatz, seit dem Tag ein, brauchten Anwendungen nicht spezifisch entworfen zu werden, um IPsec zu verwenden. Folglich schützt IPsec jeden Anwendungsverkehr über ein IP Netz. Das hält jetzt für SSL ebenso mit dem Anstieg von der gestützten VPN Revolution von SSL mit Durchführungen wie OpenVPN für wahr.

IPsec wurde ursprünglich am Marineforschungslabor als ein Teil eines GeDARPA-sponserten Forschungsprojektes entwickelt. BESONDERS wurde direkt vom SP3D Protokoll abgeleitet, anstatt ISO Network-Layer Security Protocol (NLSP) abgeleitet zu werden. Die SP3D Protokoll-Spezifizierung wurde durch NIST veröffentlicht, aber durch das Sichere Datennetzsystemprojekt von National Security Agency (NSA) entworfen, IPsec wird AH teilweise von der vorherigen IETF Standardarbeit für die Beglaubigung von Simple Network Management Protocol (SNMP) abgeleitet.

IPsec wird von Internet Engineering Task Force (IETF) in einer Reihe der Bitte um Anmerkungsdokumente offiziell angegeben, verschiedene Bestandteile und Erweiterungen richtend. Es gibt die Rechtschreibung des Protokoll-Namens an, um IPsec zu sein.

Sicherheitsarchitektur

Das IPsec Gefolge ist ein offener Standard. IPsec verwendet die folgenden Protokolle, um verschiedene Funktionen durchzuführen:

• Authentication Headers (AH) stellen connectionless Integrität und Datenursprung-Beglaubigung für IP Datenpakete zur Verfügung, und stellt Schutz gegen Wiederholungsspiel-Angriffe zur Verfügung.
• Encapsulating Security Payloads (ESP) stellen Vertraulichkeit, Datenursprung-Beglaubigung, connectionless Integrität, ein Antiwiederholungsspiel-Dienst (eine Form der teilweisen Folge-Integrität), und beschränkte Verkehrsfluss-Vertraulichkeit zur Verfügung.
• Security Associations (SA) stellen das Bündel von Algorithmen und Daten zur Verfügung, die die Rahmen zur Verfügung stellen, die notwendig sind, um AH und/oder BESONDERS Operationen zu funktionieren. Die Internetsicherheit Vereinigung und Schlüsselverwaltungsprotokoll (ISAKMP) stellt ein Fachwerk für die Beglaubigung und den Schlüsselaustausch, mit dem wirklichen beglaubigten Texteingabe-Material zur Verfügung gestellt irgendein durch die manuelle Konfiguration mit vorgeteilten Schlüsseln, Internetschlüsselaustausch (IKE und IKEv2), Kerberized Internetverhandlung von Schlüsseln (KNICK) oder IPSECKEY DNS Aufzeichnungen zur Verfügung.

Beglaubigungskopfball

Authentication Header (AH) ist ein Mitglied des IPsec Protokoll-Gefolges. AH Garantien connectionless Integrität und Datenursprung-Beglaubigung von IP Paketen. Weiter kann es gegen Wiederholungsspiel-Angriffe durch das Verwenden der gleitenden Fenstertechnik und die Verschrottung alter Pakete (sieh unten) fakultativ schützen.

• In IPv4, schützt AH die IP Nutzlast und alle Kopfball-Felder eines IP Datenpakets abgesehen von veränderlichen Feldern (d. h. diejenigen, die unterwegs verändert werden könnten), und auch IP Optionen wie die IP Sicherheitsauswahl (RFC-1108). Veränderlich (und deshalb unbeglaubigt) sind IPv4 Kopfball-Felder DSCP/TOS, ECN, Fahnen, Bruchstück-Ausgleich, TTL und Kopfball-Kontrollsumme.
• In IPv6, schützt AH den grössten Teil des IPv6-Grundkopfballs, AH selbst, der nichtveränderlichen Erweiterungskopfbälle nach AH, und die IP Nutzlast. Der Schutz für den IPv6 Kopfball schließt die veränderlichen Felder aus: DSCP, ECN, Fluss-Etikett und Sprung-Grenze.

AH funktioniert direkt oben auf IP mit dem IP Protokoll Nummer 51.

Das folgende AH Paket-Diagramm-Shows, wie AH Paket gebaut und interpretiert wird:

Folgender Kopfball (8 Bit): Der Typ des folgenden Kopfballs, anzeigend, welches Protokoll der oberen Schicht geschützt wurde. Der Wert wird von der Liste von IP Protokoll-Zahlen genommen.

Nutzlast Len (8 Bit): Die Länge dieses Beglaubigungskopfballs in 4-Oktett-Einheiten, minus 2 (ein Wert von 0 Mitteln 8 Oktette, 1 Mittel 12 Oktette, et cetera). Obwohl die Größe in 4-Oktett-Einheiten gemessen wird, muss die Länge dieses Kopfballs ein Vielfache von 8 Oktetten, wenn getragen, in einem IPv6 Paket sein. Diese Beschränkung gilt für einen in einem IPv4 Paket getragenen Beglaubigungskopfball nicht.

Vorbestellt (16 Bit): Vorbestellt für den zukünftigen Gebrauch (der ganze zeroes bis dahin).

Sicherheitsrahmen-Index (32 Bit): Willkürlicher Wert, der (zusammen mit dem Bestimmungsort IP Adresse) verwendet wird, um die Sicherheitsvereinigung der Empfang-Partei zu identifizieren.

(32 Bit): Ein Monostärkungsmittel, das ausschließlich Folge-Zahl (erhöht durch 1 für jedes Paket gesandt) steigert, um Wiederholungsspiel-Angriffe zu verhindern. Wenn Wiederholungsspiel-Entdeckung ermöglicht wird, werden Folge-Zahlen nie wiederverwendet, weil eine neue Sicherheitsvereinigung vor einem Versuch neu ausgehandelt werden muss, die Folge-Zahl außer seinem maximalen Wert zu erhöhen.

Integritätskontrolle-Wert (vielfach von 32 Bit): Kontrolle-Wert der Variablen Länge. Es kann Polstern enthalten, um das Feld zu einer 8-Oktett-Grenze für IPv6 oder einer 4-Oktett-Grenze für IPv4 auszurichten.

Sicherheit Nutzlast kurz zusammenzufassen

Encapsulating Security Payload (ESP) ist ein Mitglied des IPsec Protokoll-Gefolges. In IPsec stellt es Ursprung-Echtheit, Integrität und Vertraulichkeitsschutz von Paketen zur Verfügung. Besonders auch unterstützt Verschlüsselung-Only- und Beglaubigung-Only-Konfigurationen, aber die Verwenden-Verschlüsselung ohne Beglaubigung wird stark entmutigt, weil es unsicher ist. Verschieden von Authentication Header (AH), BESONDERS in der Transportweise stellt Integrität und Beglaubigung für das komplette nicht zur Verfügung. Jedoch, in der Tunnel-Weise, wo das komplette ursprüngliche IP Paket mit einem neuen Paket-Kopfball hinzugefügt BESONDERS kurz zusammengefasst wird, wird Schutz zum ganzen inneren IP Paket gewährt (einschließlich des inneren Kopfballs), während der Außenkopfball (einschließlich irgendwelcher IPv4 Außenoptionen oder IPv6 Erweiterungskopfbälle) ungeschützt bleibt. BESONDERS funktioniert direkt oben auf IP mit dem IP Protokoll Nummer 50.

Das folgende BESONDERS Paket-Diagramm-Shows, wie BESONDERS Paket gebaut und interpretiert wird:

Sicherheitsrahmen-Index (32 Bit): Willkürlicher Wert verwendet (zusammen mit dem Bestimmungsort IP Adresse), um die Sicherheitsvereinigung der Empfang-Partei zu identifizieren.

Folge-Zahl (32 Bit): Ein monotonically das Steigern der Folge-Zahl (erhöht durch 1 für jedes Paket gesandt), um gegen Wiederholungsspiel-Angriffe zu schützen. Es gibt einen getrennten für jede Sicherheitsvereinigung behaltenen Schalter.

Nutzlast-Daten (Variable): Der geschützte Inhalt des ursprünglichen IP Pakets, einschließlich irgendwelcher Daten hat gepflegt, den Inhalt (z.B ein Initialisation Vektor für den kryptografischen Algorithmus) zu schützen. Der Typ des Inhalts, der geschützt wurde, wird durch das Folgende Kopfball-Feld angezeigt.

Polstern (von 0-255 Oktetten): Das Polstern für die Verschlüsselung, um die Nutzlast-Daten zu einer Größe zu erweitern, die die Ziffer-Block-Größe der Verschlüsselung passt, und das folgende Feld auszurichten.

Polster-Länge (8 Bit): Größe des Polsterns (in Oktetten).

Folgender Kopfball (8 Bit): Typ des folgenden Kopfballs. Der Wert wird von der Liste von IP Protokoll-Zahlen genommen.

Integritätskontrolle-Wert (vielfach von 32 Bit): Kontrolle-Wert der Variablen Länge. Es kann Polstern enthalten, um das Feld zu einer 8-Oktett-Grenze für IPv6 oder einer 4-Oktett-Grenze für IPv4 auszurichten.

Sicherheitsvereinigung

Die IP Sicherheitsarchitektur verwendet das Konzept einer Sicherheitsvereinigung als die Basis, um Sicherheitsfunktionen in IP einzubauen. Eine Sicherheitsvereinigung ist einfach das Bündel von Algorithmen und Rahmen (wie Schlüssel), der an encrypt gewöhnt ist und beglaubigen Sie einen besonderen Fluss in einer Richtung. Deshalb, im normalen bidirektionalen Verkehr, werden die Flüsse von einem Paar von Sicherheitsvereinigungen gesichert.

Sicherheitsvereinigungen werden mit der Internetsicherheit Vereinigung und Schlüsselverwaltungsprotokoll (ISAKMP) gegründet. ISAKMP wird durch die manuelle Konfiguration mit vorgeteilten Geheimnissen, Internetschlüsselaustausch (IKE und IKEv2), Kerberized Internetverhandlung von Schlüsseln (KNICK) und der Gebrauch von IPSECKEY DNS Aufzeichnungen durchgeführt.

Um zu entscheiden, was Schutz für ein aus dem Amt scheiden Paket zur Verfügung gestellt werden soll, verwendet IPsec Security Parameter Index (SPI), einen Index zur Sicherheitsvereinigungsdatenbank (SADB) zusammen mit der Bestimmungsort-Adresse in einem Paket-Kopfball, die zusammen einzigartig eine Sicherheitsvereinigung für dieses Paket identifizieren. Ein ähnliches Verfahren wird für ein eingehendes Paket durchgeführt, wo IPsec Dekodierung und Überprüfungsschlüssel von der Sicherheitsvereinigungsdatenbank sammelt.

Für den Mehrwurf wird eine Sicherheitsvereinigung für die Gruppe zur Verfügung gestellt, und wird über alle autorisierten Empfänger der Gruppe kopiert. Es kann mehr als eine Sicherheitsvereinigung für eine Gruppe mit verschiedenem SPIs geben, dadurch vielfache Niveaus und Sätze der Sicherheit innerhalb einer Gruppe erlaubend. Tatsächlich kann jeder Absender vielfache Sicherheitsvereinigungen haben, Beglaubigung erlaubend, da ein Empfänger nur wissen kann, dass jemand, die Schlüssel wissend, die Daten gesandt hat. Bemerken Sie, dass der relevante Standard nicht beschreibt, wie die Vereinigung gewählt und über die Gruppe kopiert wird; es wird angenommen, dass eine verantwortliche Partei die Wahl gemacht haben wird.

Verfahrensweisen

IPsec kann in einer Gastgeber-zu-Gastgeber-Transportweise, sowie in einer Netztunnel-Weise durchgeführt werden.

Transportweise

In der Transportweise ist nur die Nutzlast des IP Pakets gewöhnlich encrypted und/oder beglaubigt. Die Routenplanung ist intakt, da der IP Kopfball weder modifiziert wird noch encrypted; jedoch, wenn der Beglaubigungskopfball verwendet wird, können die IP-Adressen nicht übersetzt werden, weil das den Kuddelmuddel-Wert ungültig machen wird. Der Transport und die Anwendungsschichten werden immer durch das Kuddelmuddel gesichert, so können sie nicht in jedem Fall (zum Beispiel modifiziert werden, indem sie die Hafen-Zahlen übersetzen). Transportweise wird für Gastgeber-zu-Gastgeber-Kommunikationen verwendet.

Ein Mittel, IPsec Nachrichten für das NAT Traversal kurz zusammenzufassen, ist durch RFC Dokumente definiert worden, die den NAT-T Mechanismus beschreiben.

Tunnel-Weise

In der Tunnel-Weise ist das komplette IP Paket encrypted und/oder beglaubigt. Es wird dann in ein neues IP Paket mit einem neuen IP Kopfball kurz zusammengefasst. Tunnel-Weise wird verwendet, um virtuelle private Netze für Netz-zu-Netz-Kommunikationen (z.B zwischen Routern zu schaffen, um Seiten zu verbinden), Kommunikationen des Gastgebers zum Netz (z.B entfernter Benutzerzugang) und Gastgeber-zu-Gastgeber-Kommunikationen (z.B privater Chat).

Tunnel-Weise unterstützt NAT Traversal.

Kryptografische Algorithmen

Kryptografische Algorithmen, die für den Gebrauch mit IPsec definiert sind, schließen ein:

• HMAC-SHA1 für den Integritätsschutz und die Echtheit.
• TripleDES-CBC für die Vertraulichkeit
• AES-CBC für die Vertraulichkeit.

Beziehen Sie sich auf RFC 4835 für Details.

Softwaredurchführungen

IPsec Unterstützung wird gewöhnlich im Kern mit dem Schlüsselmanagement und der ISAKMP/IKE aus dem Benutzerraum getragenen Verhandlung durchgeführt. Vorhandene IPsec Durchführungen schließen häufig beide ein.

Dort bestehen Sie mehrere Durchführungen von IPsec und ISAKMP/IKE Protokollen. Diese schließen ein:

• NRL IPsec, wo AH und BESONDERS Protokolle, und der ursprüngliche implementer der offenen Quelle IPsec für 4.4 BSD entwickelt wurden.
• OpenBSD, mit seinem eigenen Code abgeleitet aus einer BSD/OS Durchführung, die von John Ioannidis und Angelos D. Keromytis 1996 geschrieben ist.
• Der KAME-Stapel, der in Mac OS X, NetBSD und FreeBSD eingeschlossen wird.
• "IPsec" in Wacholder-Betriebssystemen
• "IPsec" in der Cisco Ein/Ausgabe-Steuersystem-Software
• "IPsec" in Windows von Microsoft, einschließlich Windows XP, Windows 2000, Windows 2003, Windows-Aussicht, Windows-Server 2008 und Windows 7.
• IPsec in der Windows-Aussicht und später
• Authentec Werkzeuge von QuickSec
• IPsec in Solaris
• IBM AIX Betriebssystem
• IBM z/OS
• IPsec und IKE im HP-UX (HP-UX IPsec)
• Der Linux IPsec Stapel, der von Alexey Kuznetsov und David S. Miller geschrieben ist.
• Openswan auf Linux, FreeBSD und Mac OS X, der den heimischen Linux IPsec Stapel oder sein eigener KLIPS-Stapel verwendet. KLIPS bietet Hardware-Beschleunigung und das SAref-Verfolgen an.
• strongSwan auf Linux, FreeBSD, Mac OS X und Androiden mit dem heimischen IPsec-Stapel.

Standardstatus

IPsec wurde in Verbindung mit IPv6 entwickelt und muss in allen standardentgegenkommenden Durchführungen von IPv6 verfügbar sein, obwohl nicht alle IPv6 Durchführungen IPsec-Unterstützung einschließen; es ist für IPv4 Durchführungen fakultativ. Jedoch, wegen der langsamen Aufstellung von IPv6, wird IPsec meistens verwendet, um IPv4 Verkehr zu sichern. IPsec Protokolle wurden RFC 1825 und RFC 1829, veröffentlicht 1995 ursprünglich definiert. 1998 wurden diese Dokumente durch RFC 2401 und RFC 2412 mit unvereinbaren Aspekten ersetzt, obwohl sie begrifflich identisch waren. Außerdem, wurde gegenseitiges Beglaubigungs- und Schlüsselaustauschprotokoll Internet Key Exchange (IKE) definiert, um Sicherheitsvereinigungen zu schaffen und zu führen. Im Dezember 2005 wurden neue Standards in RFC 4301 und RFC 4309 definiert, die größtenteils eine Obermenge der vorherigen Ausgaben mit einer zweiten Version des Internetschlüsselaustauschstandards IKEv2 sind. Diese der dritten Generation Dokumente haben die Abkürzung von IPsec zur Großschrift "IP" und Kleinbuchstabe "sec" standardisiert. Es ist ungewöhnlich, jedes Produkt zu sehen, das Unterstützung für RFCs 1825 und 1829 anbietet. "BESONDERS" allgemein bezieht sich auf RFC 2406, während sich ESPbis auf RFC 4303 bezieht.

Seit der Mitte 2008, einer IPsec Wartung und Erweiterungsarbeitsgruppe ist am IETF aktiv.

Siehe auch

• IPsec Durchgang

Informationssicherheit

• Sichere Steckdose-Schicht virtuelles privates Netz
• Opportunistische Verschlüsselung
• Dynamisches privates virtuelles Mehrpunktnetz
• tcpcrypt

Links

• Die ganze IETF aktive Sicherheit WGs
• IETF ipsecme WG ("IP Sicherheit Wartung und Erweiterungen" Arbeitsgruppe)
• IETF btns WG ("Bessere nichts Sicherheit" Arbeitsgruppe) (gechartert, um an unbeglaubigtem IPsec, IPsec APIs, Verbindung einklinkend zu arbeiten),]
• Das Sichern von Daten unterwegs mit dem Artikel IPsec WindowsSecurity.com von Deb Shinder
• IPsec am offenen Verzeichnisprojekt
• IPsec auf Microsoft TechNet
• Microsoft IPsec Diagnostic Tool auf Microsoft Download Center
• Ein illustriertes Handbuch zu IPsec durch Steve Friedl
• Sicherheitsarchitektur für IP (IPsec) Datennachrichtenvorträge durch den Teil von Manfred Lindner IPsec
• Das Schaffen von VPNs mit IPsec und SSL/TLS Linux Zeitschriftenartikel von Rami Rosen

Standards

• RFC 2367: PF_KEY Schnittstelle
• RFC 2401: Sicherheit Architektur für das Internetprotokoll (IPsec Übersicht) Veraltet durch RFC 4301
• RFC 2403: Der Gebrauch von HMAC-MD5-96 innerhalb BESONDERS und AH
• RFC 2404: Der Gebrauch von HMAC SHA 1 96 innerhalb BESONDERS und AH
• RFC 2405: BESONDERS DES-CBC Ziffer-Algorithmus Mit dem Ausführlichen IV
• RFC 2409: Der Internetschlüsselaustausch
• RFC 2410: Der UNGÜLTIGE Verschlüsselungsalgorithmus und Sein Gebrauch Mit IPsec
• RFC 2412: Das OAKLEY Schlüsselentschluss-Protokoll
• RFC 2451: BESONDERS CBC-Weise-Ziffer-Algorithmen
• RFC 2857: Der Gebrauch von HMAC RIPEMD 160 96 innerhalb BESONDERS und AH
• RFC 3526: Mehr Modular Exponential-(MODP) Diffie-Hellman Gruppen für Internet Key Exchange (IKE)
• RFC 3706: Eine Verkehrsbasierte Methode, Tote Gleiche von Internet Key Exchange (IKE) Zu entdecken
• RFC 3715: IPsec-Netzadressumrechnung (NAT) Vereinbarkeitsvoraussetzungen
• RFC 3947: Verhandlung des NAT-Traversals im IKE
• RFC 3948: UDP Encapsulation IPsec BESONDERS Pakete
• RFC 4106: Der Gebrauch der Galois/Counter Weise (GCM) in IPsec Encapsulating Security Payload (ESP)
• RFC 4301: Sicherheit Architektur für das Internetprotokoll
• RFC 4302: IP Beglaubigungskopfball
• RFC 4303: IP Sicherheit Nutzlast Kurz zusammenzufassen
• RFC 4304: Nachtrag von Extended Sequence Number (ESN) zum IPsec Gebiet der Interpretation (DOI) für die Internetsicherheit Vereinigung und Schlüsselverwaltungsprotokoll (ISAKMP)
• RFC 4306: Internetschlüsselaustausch (IKEv2) Protokoll (obsoleted durch RFC 5996)
• RFC 4307: Kryptografische Algorithmen für den Gebrauch in der Internetschlüsselaustauschversion 2 (IKEv2)
• RFC 4308: Kryptografische Gefolge für IPsec
• RFC 4309: Das Verwenden von Advanced Encryption Standard (AES) CCM Weise mit IPsec Encapsulating Security Payload (ESP)
• RFC 4478: Wiederholte Beglaubigung im Internetschlüsselaustausch (IKEv2) Protokoll
• RFC 4543: Der Gebrauch von Galois Message Authentication Code (GMAC) in IPsec BESONDERS und AH
• RFC 4555: IKEv2 Beweglichkeit und Multihoming Protokoll (MOBIKE)
• RFC 4621: Design von IKEv2 Mobility und Multihoming (MOBIKE) Protokoll
• RFC 4718: IKEv2 Erläuterungen und Durchführungsrichtlinien (obsoleted durch RFC 5996)
• RFC 4806: Erweiterungen von Online Certificate Status Protocol (OCSP) auf IKEv2
• RFC 4809: Voraussetzungen für ein IPsec Zertifikat-Verwaltungsprofil
• RFC 4835: Kryptografische Algorithmus-Durchführungsvoraussetzungen für Encapsulating Security Payload (ESP) und Authentication Header (AH)
• RFC 4945: Das Internet IP Sicherheit PKI Profil von IKEv1/ISAKMP, IKEv2 und PKIX
• RFC 5996: Internetschlüsselaustauschprotokoll-Version 2 (IKEv2)
• RFC 6071: IPsec und IKE Dokumentenfahrplan