Wie verändert die Version 2 von IKE das Verhalten?" "IKEv1 vs. v2
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Zusammenfassung und Ergänzung zum Vortrag
„IKEv1 vs. v2 –
Wie verändert die Version 2 von IKE das Verhalten?“
Von Monika Roßmanith (CNB) und Simon Rich (CN)
Somersemester 2008
Vorlesung: Netzwerksicherheit
Fachbereich: Informatik
Studiengang: Computer-Networking (-Bachelor)Inhaltsverzeichniss
Einführung .......................................................................................................................... 3
IPSec ................................................................................................................................... 3
Encapsulating Security Payload (ESP) ....................................................................... 3
Authentification Header (AH) .................................................................................... 3
Transport Mode – Tunnel Mode ................................................................................. 3
Security Association (SA)........................................................................................... 4
Security Policy Database (SPD) ................................................................................. 4
Perfect Forward Secrecy ............................................................................................. 4
IKE...................................................................................................................................... 5
IKE Phase 1................................................................................................................. 5
IKE Phase 2................................................................................................................. 5
IKEv1.......................................................................................................................... 5
IKEv2.......................................................................................................................... 6
Zusammenfassung der Unterschiede .................................................................................. 6
Quellen................................................................................................................................ 7
2Einführung
In dieser Zusammenfassung soll zuerst eine grober Überblick über IPSec und die verwendeten Terminologien gegeben
werden. Anschließend wird das Protokoll IKEv1 und IKEv2 in detaillierter Form vorgestellt und die Arbeitsweise erklärt. Im
letzten Teil werden dann die Unterschiede zwischen den beiden Versionen von IKE dargestellt. Im Anhang befindet sich
dann noch das Quellenverzeichnis.
IPSec
Bei IPSec handelt es sich um eine Sicherheitsarchitektur die für IPv6 entwickelt wurde um die Sicherheitslücken des
Internet Protokolls zu beheben. Es soll Authentizität, Vertraulichkeit und Integrität gewährleisten. IPSec unterstützt 3
Verschlüsselungsszenarien: Host-zu-Host, Host-zu-Security-Gateway und Security-Gateway-zu- Security-Gateway. Um
diese zu realisieren enthält IPSec die Protokolle AH und ESP, sowie eine Schlüsselverwaltung, die durch IKE realisiert
wird. Des Weiteren stehen 2 Modi zur Verfügung um diese Protokolle zu betreiben: Tunnelmodus und Transportmodus.
Encapsulating Security Payload (ESP)
Durch ESP wird die Vertraulichkeit der Daten oder die Authentizität der (gekapselten Daten, aber nicht die des Headers)
sichergestellt. ESP wird im Next-Header Feld des vorherigen Headers mit 50 angegeben. ESP schließt die
authentifizierten bzw. verschlüsselten Daten des IP-Payloads in einem Header und Trailer ein. Um einen möglichst
großen Bereich zu schützen, sollte der ESP-Header möglichst weit vorne im IP-Paket angeordnet sein. Allerdings dürfen
keine Informationen verschlüsselt werden die für den Transport des Pakets notwendig sind.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[2406] Abschnitt 2
Authentification Header (AH)
Der AH ist ein Protokollheader mit der Protokollnummer 51. Er beinhaltet eine digitale Signatur sowohl der enthaltenen
Nutzdaten als auch eines Teils des äußeren IP-Headers. Dies hilft die Authentizität des Absenders und die Integrität der
übermittelten Informationen sicherzustellen. Außerdem enthält er zur Verhinderung von Replay-Attacken eine
Sequenznummer. Der Empfängerhost oder -gateway kann anhand der Sequenznummer feststellen, ob das Paket schon
einmal empfangen wurde, und es gegebenenfalls verwerfen.
0 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 Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[2402] Abschnitt 2
Transport Mode – Tunnel Mode
Der Transport Modus wird nur für Verbindungen von Endpunkt zu Endpunkt genutzt. AH oder ESP transportieren die
Daten von z.B. TCP entweder authentifiziert (mit Hilfe des AH), verschlüsselt (mit Hilfe von ESP) oder beides (mit Hilfe
von ESP oder einer Kombination von AH und ESP). Die Endpunkt zu Endpunkt Nutzung von IPSec ist die einzige
Einsatzmöglichkeit des Transport Mode. Für Endpunkt zu Endpunkt Nutzung könnte auch der Tunnel Mode verwendet
werden, mit dem Nachteil das der IP-Header ein redundantes mal, in verschlüsselter Form, übertragen wird. Aus diesem
Grund wurde schon vorgeschlagen den überflüssigen Transport Mode abzuschaffen. [ferg] Seite 6;
3Der Tunnel Modus kann für verschiedene Szenarien verwendet werden:
- Endpunkt zu Endpunkt
- Endpunkt zu Security Gateway (SG), z.B. als Remote-Access für Aussendienstmitarbeiter
- SG zu SG, z.B. um Niederlassungen in ein Firmennetzwerk zu integrieren
Der Tunnel Modus kann ebenfalls wieder auf verschiedene Arten realisiert werden. Authentifiziert (mit Hilfe des AH),
verschlüsselt (mit Hilfe von ESP) oder beides (mit Hilfe von ESP oder einer Kombination von AH und ESP).
In beiden Modi, Tunnel und Transport (von dem der Transport Modus als nahezu überflüssig betrachtet werden kann),
stehen auch noch weitere Varianten mit Hilfe von AH und ESP zur Verfügung. Dies erhöht die Komplexität der IPSec-
Architektur unnötig, daher wurde vorgeschlagen das AH-Protokoll komplett aus IPSec zu entfernen. [ferg] Seite 8;
Folgendes Bild soll die verschieden Möglichkeiten, von Tunnel und Transport Modusm jeweils einmal realisiert durch AH
und einmal durch ESP, verdeutlichen:
[Bild: http://www.tech-invite.com/Security/Ti-IPSec-modes.pdf Seite 2]
Security Association (SA)
Eine SA besitzt eine Unidirektionale Gültigkeit, bis auf die initialen ISAKMP-SA’s, diese sind bidirektional. In ihr werden
die zwischen den Instanzen ausgehandelten Verfahren in Bezug auf Verschlüsselung und Authentifikation sowie
Lebensdauer der Schlüssel, Angaben über kryptographischen Synchronisation bzw. den Initialisierungsvektor und die IP
des Endsystems festgehalten. SA´s werden aus der IP-Adresse des Endpunktes und der SPI ermittelt. Die SA´s werden
in einer Security Assosiation Database (SAD) verwaltet. Am Ende einer Verbindung werden alle SA’s und deren
abgeleiteten Child-SA’s in der SAD gelöscht.
Security Policy Database (SPD)
Ähnlich eines Paketfilters, wird in IPSec jedes Paket, nach Filterregeln bearbeitet. Diese Filterregeln, so genannte
Selektoren, werden in der SPD gespeichert. Für jedes ein oder ausgehende Paket werden die Regeln in der SPD der
Reihen nach anhand der Selektoren überprüft, ob sie zu diesem Packet passen. Bei der ersten Übereinstimmung wird
das Paket diesen Regeln entsprechend bearbeitet. So sind Adress und / oder Dienst-Filterungen möglich. Diese
Selektron enthalten neben möglichen Aktionen ( apply IPSec, bypass IPSec, discard) auch Kriterien wie das zu
verwendende IPSec-Protokoll, IPSec-Modus, Auth- und Krypt-Verfahren und auch einen Zeiger auf die Zugehörige SA.
Perfect Forward Secrecy
Mit Perfect Forward Security (PFS) ist gemeint das die Kompromittierung eines einzelnen Schlüssels nur den Zugriff auf
Daten erlaubt, die von diesem einzelnen Schlüssel geschützt sind. Damit PFS funktioniert, darf z.B. der Schlüssel der die
Übertragung schütz, nicht zum herleiten weiterer Schlüssel verwendet werden. Wenn der Schlüssel, für den Schutz der
Übertragung, von anderem Schlüsselmaterial abgeleitet wurde, darf dieses Schlüsselmaterial nicht zur Ableitung weiter
Schlüssel verwendet werden. [2409] Abschnitt 3.3;
IKE (v1 und v2) stellt PFS für Schlüssel und Identitäten bereit. [2409] Abschnitt 8;
4IKE
Das IKE-Protokoll ist ein Protokoll zur Realisierung von Sicherheitsbeziehungen und zum Verhandeln und Austauschen
von authentifiziertem Schlüsselmaterial. Das IKE-Protokoll benutzt in seiner Grundlage drei Prokolle, das Internet Security
Association Key Managment Protocol (ISAKMP), Oakley und wenige teile von SKEME. ISAKMP bietet eine Umgebung
für Authentifizierung und krypthographischen Schlüsselaustausch, gibt allerdings keine Vorgaben bezüglich dieser vor.
Das IKE-Protokoll wurde so konzipiert, dass es unabhängig von Verbindungsprotkollen ist, d.h. dass es in einer Vielzahl
vonn Schlüsselaustauschszenarien eingesetzt werden kann. ISAKMP ist unabhängig von Schlüsselaustauschverfahren
und ist vor allem für die Verhandlungen der Parameter und Mechanismen zuständig.
Oakley beschreibt eine Reihe von Schlüsselaustauschverfahren und unterteilt diese entsprechend dem angestrebten Ziel
(z.B. Perfect Forward Secrecy für Schlüssel oder Schutz der Identität und Authentifizierung.
Während sich Oakley in Modi gliedert, arbeitet ISAKMP in Phasen.
[kuts] Kapitel 3
IKE Phase 1
Die erste Phase wird genutzt um mit Hilfe eines Diffie-Hellman-Verfahrens und dem Austausch von SAs eine erste
verschlüsselte und authentifizierte Verbindung zu erhalten, diese initiale ISAKMP-SAs, ist die einzige bidirektionale SA in
einer Verbindung. Diese ISAKMP-SA bleibt bis zum Ende der IPSec-Verbindung bestehen, da die Child-SAs ebenfalls
gelöscht würde, wenn man die ISAKMP-SA löscht.
IKE Phase 2
In diesem so genannten „Quick Mode“ werden weiter SAs mit dem Kommunikationspartner aufgebaut, wieder mit einem
Diffie-Hellman-Verfahren um die PFS zu gewährleisten. Dieser Mode wird immer wieder, während des bestehens einer
IPSec-Verbindung, genutzt sei es zum Aufbau von Protokoll-SAs (z.B. AH, ESP) oder zum Austausch von neuem
Schlüsselmaterial, wenn das alte abgelaufen ist.
IKEv1
Im Folgenden werden wir auf die Details in IKEv1 eingehen.
In der Phase 1 besteht die Möglichkeit aus vier verschiedenen Authentifizierungsverfahren für den initialen
Schlüsselaustausch zu wählen:
- Signaturen
- Public Key Encryption
- Revised Public Key Encryption
- Pre-Shared Keys
Des Weiteren kann innerhalb jedes dieser Verfahren zwischen zwei weiteren, unterschiedlichen Modes gewählt werden.
Das ist zum einen der Main Mode, der in den folgenden 3 Schritten (mit je 2 Nachrichten) abläuft:
1. Aushandeln der Verfahrensweise (Policy)
2. Austausch der Diffie-Hellman-Schlüsselkomponenten und für den Austausch zusätzlich benötigte
Daten (z.B. Nonces, zahlen die nur einmal benutzt werden um z.B. Replay Angriffe erkennen zu
können)
3. Authentifizierung des Diffie-Hellman-Schlüsselaustausch (Hierfür wird eins der zuvor vier
aufgelisteten Verfahren benötigt)
Der Aggressive Mode ist ähnlich wie der Main Mode aufgebaut, aber abgekürzt auf nur drei Nachrichten:
1. Der Anfragende (Alice) schlägt alle seine unterstützen Verfahrensweisen (Policys) vor, zusammen mit allen
benötigten Daten für den Schlüsselaustausch (inkl. Diffie-Hellman-Information).
2. Der Angefragte (Bob) wählt eine Verfahrensweise aus und schickt diese zusammen mit alle benötigten
Information.
3. Der Anfragende (Alice) authentifiziert seinerseits die bisherigen Session-Parameter in der dritten Nachricht an
den Angefragten (Bob).
Nach Abschluss eines dieser, insgesamt acht Verfahren, ist die Phase 1 beendet.
Die Phase 2 nutzt, die in Phase 1 ausgehandelten, Verschlüsselungen und Authentifizierungsverfahren um die
Kommunikation der 2 Phase zu schützen und zu authentifizieren. Hier in der 2 Phase werden nun Schlüssel und andere
benötigte Daten, für die Verschlüsselung und Authentifizierung der eigentlichen Datenleitungen, ausgehandelt.
Der Quick Mode besteht aus den folgenden drei Nachrichten:
1. Diffie-Hellman-Schlüsselmaterial wird an den Angerufenen (Bob) versendet (alternativ, Shared-Key
Generierungsmechanismus, dieser bietet allerdings keine PFS).
2. Der Angerufene (Bob) antwortet mit Schlüsselmaterial und den restlichen benötigten Daten.
3. Das erfolgreiche empfangen des Schlüsselmaterials wird dem Angerufenen (Bob) durch eine Conf-Nachricht
vom Anrufer (Alice) bestätigt.
Der Quick Mode in Phase 2 ist für alle acht möglichen unterschiedlichen Phase 1 Verfahren gleich.
5IKEv2
In IKEv2 ist die Phase 1 nochmals aufgeteilt in IKE_SA_INIT und IKE_AUTH, jeweils mit zwei Nachrichten. Durch den
Einsatz von IKE_AUTH mit EAP sind es in IKE_AUTH mehr wie zwei Nachrichten.
1. IKE_SA_INIT ist für den Austausch von SA’s, Diffie-Hellman-Schlüsselmaterial und den Nonces.
2. IKE_AUTH dient dazu die ersten beiden Nachrichten zu Authentifizieren, die Identitätsinformationen
auszutauschen und die erste CHILDE_SA zu erzeugen. Die Payloads des IKE_AUTH sind verschlüsselt und
authentifiziert, mit Hilfe der Schlüssel, die in der IKE_SA_INIT ausgetauscht wurden.
Die Phase 2 in IKEv2 besteht aus dem CREATE_CHILD_SA-Austausch, in diesem Teil sind alle Nachrichten
Verschlüsselt.
1. Der Anrufende (Alice) sendet eine CREATE_CHILD_SA-Anfrage, diese enthält alles benötigten Informationen
z.B. SA, Traffic Selector für beide Seiten, optional mit neuem Diffie-Hellman-Schlüsselmaterial, zu
Gewährleistung der PFS.
2. Der Angerufene (Bob) Antwortet mit allen benötigten Informationen (SA, TS und evtl. optionale Payloads).
Es gibt in IKEv2 noch weiter Typen für den Nachrichtenaustausch:
CREATE_CHILD_SA mit Schlüsselaktualisierung (optional wieder mit neuen Diffie-Hellman-Schlüsselmaterial)
INFORMATIONAL Austausch, mit dieser Payload können unterschiedliche Fehler erkannt werden. Über den
INFORMATIONAL Typ wird auch das beenden einer Verbindung dem Gegenüber mitgeteilt.
IKE_AUTH mit EAP (Extensible Authentication Protocol) ermöglich das flexible nutzen von Authentifikationsmechanismen,
z.B. für IEEE802.1x.
Zusammenfassung der Unterschiede
IKEv2 ist in einem einzigen RFC Dokument (RFC4306) spezifiziert im Gegensatz zu IKEv1, dies wurde in 3
RFCs spezifiziert (RFC2407, RFC2408, RFC2409). Zusätzlich wurden die Unterstützung von NAT Traversal,
Extensible Authentication und Remote Address hinzugefügt die zuvor nur durch proprietäre oder RFC-Draft
Erweiterungen möglich waren. Da die Komplexität des Protokolls bzw. der gesamten Architektur von IPSec
immer wieder als der Hauptkritikpunkt aufgeführt wurde, sollte diese Vereinfachung und Klarstellung zum
Abbau der Komplexität dienen. [ferg] Abschnitt 2.1; [ieee];
Zur weitern Vereinfachung wurden die 8 verschieden initialen Austauschverfahren durch einen 4 Nachrichten
umfassenden Austausch ersetzt. Diese vereinfacht vor allem den Aufbau von ISAKMP SAs, die in der ersten
Phase von IKE ausgetauscht werden. Ohne einen erfolgreichen Austausch von ISAKMP SAs können keine
IPSec-Verbindungen aufgebaut werden.
Die "Domain of Interpertation", "Situation" und "Labeled Domain Identifier" wurden entfernt.
Um die die Latenz von IKEv2 zu verringern wurde das initale Austauschverfahren auf 2 round-trips (4
Nachrichten) verkürzt. Dies wurde durch hinzufügen der Fähigkeit, Nachrichten zusammen zu packen
(piggyback), ermöglich.
Um die Implementierung des Protokolls weiter zu vereinfachen und sicherheitstechnische Analysen leichter
durchführen zu können wurde die kryptographische Syntax, um die IKE-Nachrichten zu verschlüsseln, ersetz.
Diese ist, mit kleinen Änderungen, basiert auf der von ESP.
Um die Anzahl der möglichen Fehlerzustände zu verringern wurde das Protokoll zuverlässig (alle Nachrichten
werden bestätigt) und Seqenznummern wurden eingeführt. Dies erlaubt den CREATE_CHILD_SA
Nachrichtenaustausch von 3 auf 2 Nachrichten zu verkürzen
Um die Robustheit zu verbessern (vor allem gegenüber DoS-Angriffen), muss in IKEv2 der Angefragte (Bob),
keine ausschlaggebende Bearbeitungszeit mehr für das Verarbeiten von Anfragen aufwenden und auch keine
Zustände mehr speichern, bis zu dem Zeitpunkt an dem klar ist das der Anfragende (Alice), Nachrichten an der
angegebenen IP-Adresse empfangen kann und dieser sich kryptographisch Authentifiziert hat.
Kryptographische Schwächen, wie z.B. die Symmetrie in Hashes für die Authetifizierung, wurden ausgebessert
Um "Traffic Selectors" flexibler zu gestalten wurde ein eigener Payload-Typ eingeführt. So muss die ID-Payload
nicht überladen werden, wie es in IKEv1 der Fall war. So können Parameter für die Filterung des IPSec-
Verkehrs einfacher Übergeben werden.
Das benötigte Verhalten unter bestimmten Fehlerbedingungen oder wenn unverständliche Daten erhalten
wurden, wurde spezifiziert. Dies war nötig um die Entwicklung zukünftiger Versionen zu vereinfachen ohne die
Abwärtskompatibilität unmöglich zu machen.
Zu Vereinfachung und Klarstellung wurde der gemeinsame State im Fehlerfall oder bei DoS-Angriffen definiert.
U.a. ist so ein totes Gegenüber deutlicher einfacher zu erkennen, die zur Verbindung gehörenden SAs können
gelöscht werden und ein Neustart des Protokollablaufs wird schneller eingeleitet.
Um den Portierungsaufwand bei alten IKEv1 Implementierungen auf IKEv2 so einfach wie möglich zu halten
wurden bestehende Syntax und die Magic Numbers erweitert.
[4306] Anhang A;
6Quellen
[2402] S. Kent, R. Atkinson, "IP Authentication Header"; RFC 2402, Nov 1998, http://tools.ietf.org/rfc/rfc2402.txt
[2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)"; RFC 2406, Nov 1998,
http://tools.ietf.org/rfc/rfc2406.txt
[2407] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP"; RFC 2407, Nov 1998,
http://tools.ietf.org/rfc/rfc2407.txt
[2408] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management
Protocol (ISAKMP)"; RFC 2408, Nov 1998, http://tools.ietf.org/rfc/rfc2408.txt
[2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)"; RFC 2409, Nov 1998,
http://tools.ietf.org/rfc/rfc2409.txt
[4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol"; RFC 4306, Dez 2005,
http://tools.ietf.org/rfc/rfc4306.txt
[4308] P. Hoffman, "Cryptographic Suites for IPsec"; RFC 4308, Dez 2005, http://tools.ietf.org/rfc/rfc4308.txt
[4718] P. Eronen, P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines"; RFC 4718, Okt 2006,
http://tools.ietf.org/rfc/rfc4718.txt
[para] "IKEv2 Parameters - per [RFC4306]"; http://www.iana.org/assignments/ikev2-parameters
[regi] "Internet Key Exchange (IKE) Attributes - per RFC 2409 (IKE)"; http://www.iana.org/assignments/ipsec-
registry
[sous] H. Soussi, M. Hussain, H. Afifi, D. Seret, "IKEv1 and IKEv2: A Quantitative Analyses"; http://www.math-
info.univ-paris5.fr/~seret/paperb4F.pdf
[huss] M. Hussain, I. Hajjeh H. Afifi, D. Seret, "Tri-party IKEv2 in Home Networks"; http://www.math-info.univ-
paris5.fr/~seret/IKEv2-TriParty-mhn.pdf
[ferg] N. Ferguson, B. Schneier "A Cryptographic Evaluation of IPSec"; http://www.schneier.com/paper-
ipsec.html
[ieee] R. Perlman, C. Kaufmann, "Key Exchange in IPSec: Analysis of IKE"; IEEE Internet Computing, Vol. 4
Issue: 6, Nov-Dez 2000,
http://ieeexplore.ieee.org/iel5/4236/19367/00895016.pdf?tp=&isnumber=&arnumber=895016
[stef] A. Steffen, "Leichter tunneln - IPSec-VPNs werden einfacher und flexibler dank IKEv2";
http://www.heise.de/security/Einfacher-VPN-Tunnelbau-dank-IKEv2--/artikel/102744
[rich] M. Richter, "IPSec - Grundlagen"; http://www.sec.informatik.tu-darmstadt.de/pages/lehre/WS02-
03/seminar/ausarbeitungen/IPSecI.pdf
[kuts] R. Kutsch, "Internet Key Exchange"; http://krypt.cs.uni-
sb.de/teaching/seminars/ws2001/final/writeups/9.pdf
[ecke] C. Eckert, "IT-Sicherheit: Konzepte – Verfahren - Protokolle"; Oldenbourg Wissenschaftsverlg
[bles] R. Bless, E. Blaß, M. Conrad, H. Hof, K. Kutzner, S. Mink, M. Schölle, "Sichere Netzwerkkommunikation:
Grundlagen, Protokolle und Architekturen"; Springer Verlag
[gema] Gematik – Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH"Einführung der
Gesundheitskarte - Netzwerkspezifikation";
http://www.dimdi.de/dynamic/de/ehealth/karte/downloadcenter/technik/kartenspezifikation/spez_testphase_ar
chiv/spez_testphase_archiv_5_netz/netzwerkspezifikation_v1-0-0.pdf
7Sie können auch lesen
