In the Code: IPsec ineffizient und veraltet, aber unverzichtbar

Christoph Jaggi erklärt, warum IPsec weiterhin unverzichtbar ist, und welche Security-Probleme der seit 2005 nur noch fakultative Authentication Header verursacht.
 
Schaut man sich die Geschichte von IPsec an, dann fallen zwei Dinge auf: Es gibt drei Versionen, welche die jeweils vorherige obsolet machten. Die erste stammt aus dem Jahr 1995, die zweite aus dem Jahr 1998 und die dritte aus dem Jahr 2005. Der aktuelle Stand der Architektur stammt aus dem Dezember 2005. Einige Implementationsvorgaben in Bezug auf die Verwendung von Verschlüsselungsalgorithmen sind hingegen älter und wurden (noch) nicht angepasst.
 
Fakultativer Authentication Header seit 2005
Was die aktuelle Version von IPsec von der vorherigen Version unterscheidet ist der Wegfall der Pflicht zur Unterstützung des Authentication Header (AH). Für die Sicherheit des Netzwerkverkehrs zwischen zwei Punkten unterstützt IPsec zwei Sicherheitsprotokolle, Authentication Header (AH) und Encapsulating Payload (ESP). AH stellt Integrität und Datenursprung des Pakets sicher, während ESP die Nutzlast verschlüsselt und deren Integrität und Datenursprung sichert.
 
In der aktuellen Version von IPsec ist die Unterstützung und Verwendung des Authentication Headers fakultativ. Ohne AH bleibt aber der Header ungeschützt. Der Schutz gegen Spoofing und Insertions-Attacken ist weg.
 
Schutz des Headers
Nebst dem AH gibt es zwei andere technische Möglichkeiten, den Header effizient zu schützen. Die eine ist der Einbezug des Headers in die Additional Data eines AEAD-Cipher wie AES-GCM. Bei einer AEAD-Cipher können nebst der verschlüsselten Nutzlast zusätzliche Daten authentisiert werden. Integrität und Datenursprung des Headers können so einfach und effizient sichergestellt werden. Die andere Möglichkeit ist die Erweiterung der Abdeckung des Integritätsschutzes und der Datenursprungsbestätigung auf den Header. Das funktioniert zum Beispiel. in der Kombination von AES-CBC mit SHA512.
 
Es gibt nur ein Problem: Die IETF RFCs zur Verwendung von AES-GCM und SHA2 schliessen eine solche Abdeckung aus. Die historische Ursache: Beide RFCs wurden vor der Veröffentlichung der aktuellen Version von IPsec geschrieben und veröffentlicht, als der Authentication Header noch Pflicht war.
 
Das Problem mit Authentication Header
AH bringt gleich in zwei Bereichen Nachteile mit sich: Der Verarbeitung und dem Overhead. Für das, was sich technisch ohne zusätzlichen Overhead lösen liesse, generiert AH einen Overhead von 28 Bytes pro Paket. Zusätzlich braucht es mehr Verarbeitungsschritte, da es für den AH eine eigene Security Association (SA) braucht und das Sicherheitsprotokoll vor der Verschlüsselung und nach der Entschlüsselung der Nutzlast ausgeführt wird. Aufgrund der Ineffizienz ist es durchaus nachvollziehbar, dass die meisten Anbieter von Sicherheitsprodukten und Produkten mit IPsec-Funktionalität den AH nicht mehr unterstützen. Dadurch ergeben sich aber auch zusätzliche Angriffsvektoren, die ausgenützt werden können.
 
Grundregeln der Netzwerkverschlüsselung
Im Bereich der Netzwerkverschlüsselung ist der beste Schutz derjenige, der soviel verschlüsselt wie möglich und so viele Teile des Pakets oder Frames wie möglich mit Integritätsschutz und Datenursprungbestätigung versieht. Nur die Felder, die sich während des Transports ändern dürfen können nicht mit Integritätsschutz kombiniert mit Datenursprungsbestätigung versehen werden.
 
Network Address Translation (NAT) führt dazu, dass sich gewisse Adressfelder während des Transports ändern können. Es gibt Anbieter, die es erlauben, den durch die Authentisierung zu schützenden Bereich zu definieren und in Felder aufzuteilen. Damit lassen sich Felder, die sich während dem Transport ändern dürfen, von der Authentisierung aussparen.
 
Unterschiede in den IP-Netzwerken
Nicht jedes IP-Netzwerk verändert ein Feld des Headers während des Transports. Bei IP-Netzwerken kommt es darauf an, ob es sich um IPv4 oder IPv6 handelt, um welche Art von Adressen es sich handelt und ob es sich um statische oder dynamische Verbindungen handelt. Zusätzlich kommt es drauf an, ob NAT verwendet wird und wann die Verschlüsselung erfolgt.
 
Das Problem mit der Industrie
Die Industrie gibt sich dynamisch und fortschrittlich. Das ist Marketing. Die IETF gibt sich sicherheitsorientiert und zeitgemäss. Leider ist die IETF – übrigens gleich wie die NIAP – herstellerhörig. Nicht die Sicherheit steht im Fokus, sondern die Industrieinteressen. Die Wahl der zu authentisierenden Felder des Headers findet sich deshalb weder in IETF RFCs noch in den Produkten der volumenmässigen Marktführer.
 
Für die Industrie im Allgemeinen scheint es einfacher, den Entwicklungsaufwand zu minimieren und die entsprechenden standardsetzenden Gremien in ihrem Interesse zu beeinflussen. Mit dem Kriterium "Interoperabilität" lässt sich Fortschritt vordergründig im Zaun halten.
 
IPsec ist unverzichtbar
IPsec als interoperable Sicherheitsarchitektur für IP-Netzwerke ist unverzichtbar. Das heisst allerdings nicht, dass die IPsec-Architektur und die Verwendung von Algorithmen auf dem Stand von 2005 eingefroren werden müssen.
 
Beim Internet Key Exchange (IKE) hat sich sowohl die Architektur als auch der Bereich der unterstützen und erforderten Algorithmen weiterentwickelt. Im Bereich "Traffic Security" gilt allerdings immer noch der Stand von Dezember 2005. Die letzten 14 Jahre brachten keinen Fortschritt. Der Wegfall der Pflicht zur Unterstützung des Authentication Header war allerdings sicherheitstechnisch ein Rückschritt.
 
Wie lässt sich das ändern?
Es liegt an mehreren Parteien, IPsec den aktuellen Anforderungen und Möglichkeiten anzupassen: Den Anbietern, der IETF und den Kunden. Solange Kunden nicht darauf schauen, was sie genau kaufen und welcher Schutz gewährt wird, sind sie mitschuldig an der aktuellen Situation. Der Sicherheitsexperte Bruce Schneier hat das äusserst treffend artikuliert: "Der Markt belohnt Time-to-Market, Performance und Preis. Sicherheit und Langlebigkeit werden kaum beachtet. Das ist ein Marktversagen".
 
Alternativen gibt es nur für Teilbereiche
Für standortübergreifende IP-Netzwerke gibt es Lösungen, welche für die Verschlüsselung nicht IPsec verwenden und deshalb nicht mit IPsec interoperabel sind. Dafür lösen sie die Absicherung von IP-Netzwerken effizienter und decken bei der Authentisierung auch den Header ab. Für Interoperabilität mit IPsec braucht es aber IPsec. (Christoph Jaggi)