Internet Key Exchange

Internet Key Exchange (IKE) is een populair encryptieprotocol dat wereldwijd wordt toegepast voor VPN-verbindingen. Het protocol zorgt ervoor dat client en server elkaar herkennen en via het IPsec-protocol een beveiligde verbinding kunnen opbouwen voor het verzenden van gegevens.^[1]

IKE bouwt voort op het Oakley-protocol en ISAKMP.^[2] De Internet Engineering Task Force (IETF) definieerde IKE oorspronkelijk in november 1998 in een reeks publicaties (Request for Comments of RFC):

• RFC 2407 definieerde het Internet IP Security Domain of Interpretation voor ISAKMP.^[3]
• RFC 2408 definieerde het Internet Security Association en Key Management Protocol (ISAKMP).^[4]
• RFC 2409 definieerde de Internet Key Exchange (IKE).^[5]

In december 2005 werd met RFC 4306 de IKE bijgewerkt naar versie twee.^[6] Met RFC 4718 werden in oktober 2006 enkele details verduidelijkt.^[7] RFC 5996 combineerde deze twee documenten en voegde hier aanvullende verduidelijkingen aan toe in IKEv2, die werd uitgegeven in september 2010.^[8]

Een latere update zorgde ervoor dat het concept een volledige internetstandaard werd, die in oktober 2014 is uitgegeven als RFC 7296.^[9]

De moederorganisatie van de IETF, de Internet Society (ISOC), handhaaft de auteursrechten van deze standaarden als vrij beschikbaar voor de internetgemeenschap.

De meeste IPsec-implementaties bestaan uit een IKE-daemon die in de gebruikersomgeving draait en een IPsec-stack in de kernel die de daadwerkelijke IP-packets verwerkt.

Daemons in de gebruikersomgeving hebben indien nodig eenvoudig toegang tot massaopslag met configuratie-informatie, zoals de IPsec-eindpuntadressen, sleutels en certificaten. Kernelmodules daarentegen kunnen packets efficiënt en met minimale overhead verwerken, wat belangrijk is om prestatieredenen.

Het IKE-protocol gebruikt X.509-certificaten voor authenticatie – vooraf gedeeld of gedistribueerd via DNS (bij voorkeur met DNSSEC) – en een Diffie-Hellman-sleuteluitwisseling om een gedeeld sessiegeheim op te zetten waaruit cryptografische sleutels worden afgeleid. Bovendien moet er handmatig een beveiligingsbeleid worden bijgehouden voor elke peer die verbinding maakt.^[10]

Het IKE-protocol maakt gebruik van UDP-packets, meestal op poort 500, en vereist doorgaans 4 à 6 packets met 2 à 3 round-trips om aan beide kanten een ISAKMP- security association (SA) te creëren. De uitgewisselde sleutel wordt vervolgens aan de IPsec-stack doorgegeven. Dit kan bijvoorbeeld een AES-sleutel zijn, informatie die de te beschermen IP-eindpunten en poorten identificeert, evenals welk type IPsec-tunnel er is gemaakt. De IPsec-stack onderschept op zijn beurt de relevante IP-packets indien en waar nodig en voert indien nodig versleuteling/ontsleuteling uit. Implementaties variëren afhankelijk van de manier waarop de packets worden onderschept. Sommige implementaties gebruiken bijvoorbeeld virtuele apparaten, anderen halen een stukje uit de firewall, enz.

IKEv1 bestaat uit twee fasen: fase 1 en fase 2.^[11]

Het doel van IKE fase één is om een veilig geauthenticeerd communicatiekanaal tot stand te brengen door het Diffie-Hellman sleuteluitwisselingsalgoritme te gebruiken om een gedeelde geheime sleutel te genereren, voor het versleutelen van verdere IKE-communicatie. Deze onderhandeling resulteert in één enkele bidirectionele ISAKMP-security association.^[12] De authenticatie kan worden uitgevoerd met behulp van een pre-shared key (gedeeld geheim), handtekeningen of versleuteling met een openbare sleutel.^[13] Fase 1 werkt in de "Main Mode" of de "Aggressive Mode". De Main Mode beschermt de identiteit van de peers en de hash van de gedeelde sleutel door ze te versleutelen; Aggressive Mode doet dit niet.^[11]

Tijdens fase twee van IKE gebruiken de IKE-peers het beveiligde kanaal dat in fase 1 is opgezet om te onderhandelen over security associations namens andere services zoals IPsec. De onderhandeling resulteert in minimaal twee unidirectionele security associations (één inkomend en één uitgaand).^[14] Fase 2 werkt alleen in Quick Mode.^[11]

Oorspronkelijk had IKE talrijke configuratieopties, maar miste het een algemene mogelijkheid voor automatische onderhandelingen over een bekend standaardgeval dat universeel wordt geïmplementeerd. Bijgevolg moesten beide partijen van een IKE het precies eens worden over het type security association dat ze wilden creëren – optie voor optie – of er kon geen verbinding tot stand worden gebracht. Verdere complicaties kwamen voort uit het feit dat in veel implementaties de debug-uitvoer moeilijk te interpreteren was, als er al enige mogelijkheid was om diagnostische uitvoer te produceren.

De IKE-specificaties stonden open voor een aanzienlijke mate van interpretatie, grenzend aan ontwerpfouten (Dead Peer Detection is hiervan een voorbeeld), wat aanleiding gaf tot verschillende IKE-implementaties die helemaal niet in staat waren om een overeengekomen security association te creëren voor veel combinaties van opties, hoe correct geconfigureerd ze ook aan beide kanten zouden lijken.

Het IKEv2-protocol werd in 2005 beschreven in bijlage A van de RFC 4306. De volgende problemen zijn aangepakt:

• Minder Request for Comments (RFC's): De specificaties voor IKE kwamen aan bod in ten minste drie RFC's, meer als je rekening houdt met NAT traversal en andere extensies die algemeen worden gebruikt. IKEv2 combineert deze in één RFC en brengt ook verbeteringen aan ter ondersteuning van NAT-traversal (Network Address Translation (NAT)) en firewall traversal in het algemeen.
• Standaardmobiliteitsondersteuning: Er is een standaardextensie voor IKEv2 genaamd [rfc:4555 Mobility and Multihoming Protocol] (MOBIKE) (zie ook IPsec) die wordt gebruikt om mobiliteit en multihoming daarvoor te ondersteunen en Encapsulated Security Payload (ESP). Door gebruik te maken van deze extensie kunnen IKEv2 en IPsec gebruikt worden door mobiele en multihomed gebruikers.
• NAT traversal : Door de inkapseling van IKE en ESP in het User Datagram Protocol (UDP-poort 4500) kunnen deze protocollen door een apparaat of firewall gaan die NAT uitvoert.^[15]
• Ondersteuning voor Stream Control Transmission Protocol (SCTP): IKEv2 staat het SCTP-protocol toe zoals deze wordt gebruikt in het internettelefonieprotocol, Voice over IP (VoIP).
• Eenvoudige berichtenuitwisseling: IKEv2 heeft één aanvankelijk uitwisselingsmechanisme met vier berichten, waarbij IKE acht duidelijk verschillende initiële uitwisselingsmechanismen bood, die elk kleine voor- en nadelen hadden.
• Minder cryptografische mechanismen: IKEv2 gebruikt cryptografische mechanismen om zijn packets te beschermen die sterk lijken op wat IPsec ESP gebruikt om de IPsec-packets te beschermen. Dit leidde tot eenvoudigere implementaties en certificeringen voor Common Criteria en FIPS 140-2 (Federal Information Processing Standard (FIPS), waarbij elke cryptografische implementatie afzonderlijk moet worden gevalideerd.
• Betrouwbaarheid en statusbeheer: IKEv2 maakt gebruik van volgnummers en bevestigingen om betrouwbaarheid te bieden en vereist een bepaalde foutverwerkingslogistiek en gedeeld statusbeheer. IKE zou in een "dode toestand" terecht kunnen komen als gevolg van het ontbreken van dergelijke betrouwbaarheidsmaatregelen, waarbij beide partijen verwachtten dat de ander een actie onderneemt, wat nooit plaatsvindt. Er werden oplossingen ontwikkeld (zoals Dead-Peer-Detection) maar deze waren niet gestandaardiseerd. Dit betekende dat verschillende implementaties van work-arounds niet altijd compatibel waren.
• Veerkracht bij Denial of Service (DoS)-aanvallen: IKEv2 voert niet veel verwerkingen uit totdat wordt vastgesteld of de aanvrager daadwerkelijk bestaat. Hiermee werd een aantal van de DoS-problemen opgelost waarmee IKE te kampen had, waardoor veel dure cryptografische verwerkingen vanaf gespoofte locaties zou worden uitgevoerd.

De IETF ipsecme-werkgroep heeft een aantal extensies gestandaardiseerd, met als doel het IKEv2-protocol te moderniseren en beter aan te passen aan productieomgevingen met grote volumes. Deze extensies omvatten:

• IKE session resumption: de mogelijkheid om een mislukte IKE/IPsec-sessie te hervatten na een fout, zonder dat u het volledige IKE-installatieproces hoeft te doorlopen.^[16]
• IKE redirect : omleiding van inkomende IKE-verzoeken, waardoor eenvoudige taakverdeling tussen meerdere IKE-eindpunten mogelijk is.^[17]
• IPsec traffic visibility: speciale tagging van ESP-packets die zijn geverifieerd maar niet versleuteld, met als doel het voor middleboxes (zoals Intrusion detection systemen) gemakkelijker te maken om de stroom te analyseren.^[18]
• Mutual EAP authentication: ondersteuning voor alleen EAP-authenticatie (dwz certificaatloze) authenticatie van beide IKE-peers; het doel is om het gebruik van moderne , op wachtwoorden gebaseerde authenticatiemethoden mogelijk te maken.^[19]
• Quick crash detection: minimaliseert de tijd totdat een IKE-peer detecteert dat zijn andere peer is gecrasht.^[20]
• Hoge beschikbaarheid-extensies: verbetering van protocolsynchronisatie op IKE/IPsec-niveau tussen een cluster van IPsec-eindpunten en een peer, om de kans op verbroken verbindingen na een failover-gebeurtenis te verkleinen.^[21]

IKE wordt ondersteund als onderdeel van de IPsec-implementatie in Windows 2000, XP, Server 2003, Vista en Server 2008.^[22] De ISAKMP/IKE-implementatie is gezamenlijk ontwikkeld door Cisco en Microsoft.^[23] Microsoft Windows 7 en Windows Server 2008 R2 ondersteunen gedeeltelijk IKEv2^[9] en MOBIKE^[24] via de VPN Reconnect- functie (ook bekend als Agile VPN).

Er zijn verschillende open source-implementaties van IPsec met bijbehorende IKE-mogelijkheden. Op Linux bieden Libreswan, Openswan en strongSwan een IKE-daemon die de KLIPS- of XFRM/NETKEY-kernel-gebaseerde IPsec-stacks kan configureren (d.w.z. Security Associations opzetten). XFRM/NETKEY is de Linux-native IPsec-implementatie die beschikbaar is vanaf Linuxkernel 2.6.

Berkeley Software Distribution implementeert ook IPsec/IKE daemon, via het OpenBSD Cryptographic Framework (OCF), wat het ondersteunen van cryptographic accelerators veel eenvoudiger maakt. OCF is onlangs geporteerd naar Linux.

De volgende open source-implementaties van IKEv2 zijn beschikbaar:

• OpenIKEv2,^[25]
• strongSwan,
• Libreswan,
• Openswan,
• Racoon van het KAME-project,
• iked van het OpenBSD-project.^[26]

Een aantal leveranciers van netwerkapparatuur hebben hun eigen IKE-daemons (en IPsec-implementaties) gemaakt, of hebben een licentie voor een stack van elkaar.

Uitgelekte NSA-presentaties die in 2014 door Der Spiegel zijn uitgebracht, geven aan dat IKE op onbekende wijze wordt uitgebuit om IPsec-verkeer te ontsleutelen, net als ISAKMP. De onderzoekers die de Logjam-aanval ontdekten, stellen dat het slopen van een 1024-bit Diffie-Hellman-groep 66% van de VPN-servers, 18% van de top miljoen HTTPS-domeinen en 26% van de SSH-servers zou slopen, wat volgens de onderzoekers overeenkomt met de gelekte presentaties. Deze bewering werd in 2015 weerlegd door zowel Eyal Ronen als Adi Shamir in hun paper "Critical Review of Imperfect Forward Secrecy"^[27] en door Paul Wouters van Libreswan in een artikel uit 2015 "66% van de VPN's is in feite niet kapot"^[28]

IPsec VPN-configuraties die onderhandeling over meerdere configuraties mogelijk maken, zijn onderhevig aan op Man-in-the-middle-aanval gebaseerde downgrade-aanvallen tussen de aangeboden configuraties, met zowel IKEv1 als IKEv2.^[29] Dit kan worden vermeden door het toepassen van zorgvuldige scheiding van clientsystemen op meerdere servicetoegangspunten met striktere configuraties.

Beide versies van de IKE-standaard zijn gevoelig voor een offline woordenboekaanval wanneer een wachtwoord met lage entropie wordt gebruikt. Voor IKEv1 geldt dit voor de Main Mode en de Aggressive Mode.^[30][31][32]

• Computernetwerk
• IPsec