Cryptography Reference
In-Depth Information
Schlüssel kennen, hat Mallory keine Chance, das Paket unbemerkt zu ändern.
Die AH-Spezifikation legt nicht fest, welche kryptografische Hashfunktion hier-
bei verwendet wird. Die RFCs, die den Einsatz von kryptografischen Hashfunk-
tionen in ESP behandeln, sehen für AH dieselben Verfahren wie für ESP vor. Als
kryptografische Hashfunktion können demnach MD5 [RFC2403], SHA-1
[RFC2404] und RIPEMD-160 [RFC2857] eingesetzt werden. Alice und Bob
können auch andere Verfahren verwenden, wenn beide diese unterstützen. Prinzi-
piell kann statt einer schlüsselabhängigen Hashfunktion auch ein digitales Signa-
turverfahren zum Einsatz kommen. Da digitale Signaturen jedoch bekannterma-
ßen recht langsam sind und unterhalb der Anwendungsebene kaum einen Sinn
haben, ist dies nicht üblich.
Ähnlich wie ESP kann auch AH im Transport- und im Tunnel-Modus ein-
gesetzt werden. Die Funktionsweise ist analog zu der von ESP: Im Transport-
Modus wird ein bestehendes IP-Paket erweitert, im Tunnel-Modus wird ein
gesamtes IP-Paket in den Nutzdatenteil eines neuen IP-Pakets gepackt.
34.2
IKE
IPsec unterstützt zwar Kontexte und Assoziationen, kann diese jedoch nicht ver-
walten und ist für sich genommen weder verhandlungsfähig noch zustandsbehaf-
tet. Zudem setzt IPsec voraus, dass Alice und Bob einen gemeinsamen geheimen
Schlüssel besitzen, wobei kein Schlüsselaustausch spezifiziert wird. Ein leistungs-
fähiges Werkzeug wird aus IPsec daher nur im Zusammenspiel mit einem zusätz-
lichen Protokoll, das sich um die fehlenden Belange kümmert. Das von der IETF
hierfür vorgesehene Protokoll hat den Namen
IKE
(
Internet Key Exchange
). Es
wird in [RFC5996] beschrieben.
Während bei der Entwicklung von IPsec halbwegs Einigkeit über den zu wäh-
lenden Ansatz herrschte, sorgte IKE innerhalb der IETF für heftige Diskussionen.
Es gab im Wesentlichen zwei Lager: Die einen wollten IKE als möglichst flexibles
und funktionsreiches Schicht-7-Protokoll realisieren. Dazu schlugen sie einen
Entwurf vor, der auf drei bereits vorhandenen Protokollen (ISAKMP, Oakley und
SKEME) basierte. Den anderen war dieser Ansatz zu kompliziert. Sie bevorzug-
ten das deutlich einfachere
Simple Key Management Protocol
(
SKIP
), das in
Schicht 3 des OSI-Modells ansetzt und weniger Funktionalität bietet. Nach lan-
gen Diskussionen machte die ISAKMP-Oakley-SKEME-Fraktion das Rennen. So
kommt es, dass IKE ein recht komplexes Protokoll ist, das dafür jedoch eine Viel-
zahl von Möglichkeiten bietet.
