En informàtica, l'intercanvi de claus d'Internet (IKE, versionat com a IKEv1 i IKEv2) és el protocol utilitzat per establir una associació de seguretat (SA) al conjunt de protocols IPsec. IKE es basa en el protocol Oakley i ISAKMP.The Internet Key Exchange (IKE), RFC 2409, §1 Abstract IKE utilitza certificats X.509 per a l'autenticació, ja sigui precompartits o distribuïts mitjançant DNS (preferiblement amb DNSSEC), i un intercanvi de claus Diffie-Hellman per establir un secret de sessió compartit del qual es deriven les claus criptogràfiques. Actualment s'està escrivint un esborrany de l'IETF per proporcionar un establiment de claus resistent als atacs quàntics mitjançant ML-KEM. A més, s'ha de mantenir manualment una política de seguretat per a cada peer que es connecti.
Història L'Internet Engineering Task Force (IETF) va definir originalment IKE el novembre de 1998 en una sèrie de publicacions (Sol·licitud de comentaris) conegudes com a RFC 2407, RFC 2408 i RFC 2409:
RFC 2407 va definir el domini d'interpretació de la seguretat IP d'Internet per a ISAKMP. RFC 2408 va definir l'Associació de Seguretat d'Internet i Key Management Protocol (ISAKMP). RFC 2409 va definir el Internet Key Exchange (IKE).
updated IKE to version two (IKEv2) in December 2005. RFC 4718 clarified some open details in October 2006. RFC 5996 combined these two documents plus additional clarifications into the updated IKEv2, published in September 2010. A later update upgraded the document from Proposed Standard to Internet Standard, published as RFC 7296 in October 2014.
L'organització matriu de l'IETF, l'Internet Society (ISOC), ha mantingut els drets d'autor d'aquests estàndards com a disponibles gratuïtament per a la comunitat d'Internet.
Arquitectura La majoria de les implementacions d'IPsec consisteixen en un daemon IKE que s'executa a l'espai d'usuari i una pila d'IPsec al nucli que processa els paquets IP reals.
Els daemons de l'espai d'usuari tenen fàcil accés a l'emmagatzematge massiu que conté informació de configuració, com ara les adreces de punt final IPsec, les claus i els certificats, segons calgui. Els mòduls del nucli, en canvi, poden processar paquets de manera eficient i amb una sobrecàrrega mínima, cosa que és important per motius de rendiment.
El protocol IKE utilitza paquets UDP, normalment al port 500, i generalment requereix de 4 a 6 paquets amb 2 o 3 viatges d'anada i tornada per crear una associació de seguretat (SA) ISAKMP a banda i banda. El material de la clau negociada es dóna a la pila IPsec. Per exemple, això podria ser una clau AES, informació que identifica els punts finals IP i els ports que s'han de protegir, així com quin tipus de túnel IPsec s'ha creat. La pila IPsec, al seu torn, intercepta els paquets IP rellevants si és apropiat i realitza el xifratge/desxifratge segons calgui. Les implementacions varien en com es fa la intercepció dels paquets; per exemple, alguns utilitzen dispositius virtuals, altres prenen una part del tallafocs, etc.
L'IKEv1 consta de dues fases: la fase 1 i la fase 2."RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
Fases de l'IKEv1 L'objectiu de la fase 1 d'IKE és establir un canal de comunicació autenticat i segur mitjançant l'algoritme d'intercanvi de claus Diffie-Hellman per generar una clau secreta compartida per xifrar futures comunicacions IKE. Aquesta negociació resulta en una única associació de seguretat ISAKMP bidireccional."RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 6 L'autenticació es pot realitzar mitjançant una clau precompartida (secret compartit), signatures o xifratge de clau pública."RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 10-16 La fase 1 funciona en mode principal o en mode agressiu. El mode principal protegeix la identitat dels iguals i el hash de la clau compartida xifrant-los; el mode agressiu no ho fa."RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
Durant la fase dos d'IKE, els nodes IKE utilitzen el canal segur establert a la fase 1 per negociar associacions de seguretat en nom d'altres serveis com IPsec. La negociació resulta en un mínim de dues associacions de seguretat unidireccionals (una d'entrada i una de sortida)."RFC 4306 Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p. 11,33 La fase 2 només funciona en mode ràpid."RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
Problemes amb IKE Originalment, IKE tenia nombroses opcions de configuració però no tenia una funció general per a la negociació automàtica d'un cas per defecte universalment compatible. Com a resultat, tots dos punts finals havien d'estar exactament d'acord en tots els paràmetres de l'associació de seguretat, com ara algoritmes de xifratge, mètodes d'intercanvi de claus i temps de vida, o la connexió fallaria. Això va provocar freqüents problemes d'interoperabilitat entre les implementacions de diferents proveïdors. La resolució de problemes es complicava encara més per la sortida de depuració limitada o críptica en moltes implementacions.
Les especificacions de l'IKEv1 també permetien un grau significatiu d'interpretació, que de vegades vorejava els defectes de disseny. Un exemple és la Detecció de Parells Morts (DPD), que es va implementar de manera inconsistent entre els proveïdors. Fins i tot amb configuracions correctament coincidents, això podria provocar errors de negociació o túnels perduts.
Millores amb IKEv2 El protocol IKEv2 es va descriure a l'Apèndix A de la RFC 4306 el 2005. Es van abordar els següents problemes:
Menys sol·licituds de comentaris (RFC): Les especificacions per a IKE es van tractar en almenys tres RFC, més si es té en compte la travessa NAT i altres extensions que s'utilitzen habitualment. IKEv2 combina aquestes en una sola RFC, a més de millorar la compatibilitat amb la travessa NAT (traducció d'adreces de xarxa (NAT)) i el travessar de tallafocs en general. Suport de mobilitat estàndard: Hi ha una extensió estàndard per a IKEv2 anomenada [rfc:4555 Mobility and Multihoming Protocol] (MOBIKE) (vegeu també, IPsec) que s'utilitza per donar suport a la mobilitat i el multihoming per a aquest i a l'encapsulació de la càrrega útil de seguretat (ESP). Mitjançant l'ús d'aquesta extensió, els usuaris mòbils i multihomed poden utilitzar IKEv2 i IPsec. Travessa NAT: L'encapsulació d'IKE i ESP en el protocol de datagrames d'usuari (port UDP 4500) permet que aquests protocols passin a través d'un dispositiu o tallafocs que realitza NAT."RFC 4306: Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p 38-40 Compatibilitat amb el protocol de transmissió de control de flux (SCTP): IKEv2 permet el protocol SCTP tal com s'utilitza en el protocol de telefonia per Internet, Veu sobre IP (VoIP). Intercanvi de missatges simple: IKEv2 té un mecanisme d'intercanvi inicial de quatre missatges, mentre que IKE proporcionava vuit mecanismes d'intercanvi inicial clarament diferents, cadascun dels quals tenia lleugers avantatges i desavantatges. Menys mecanismes criptogràfics: IKEv2 utilitza mecanismes criptogràfics per protegir els seus paquets que són molt similars als que utilitza IPsec ESP per protegir els paquets IPsec. Això va conduir a implementacions i certificacions més senzilles per a Common Criteria i FIPS 140-2 (Federal Information Processing Standard (FIPS), que requereixen que cada implementació criptogràfica es validi per separat. Fiabilitat i gestió de l'estat: IKEv2 utilitza números de seqüència i reconeixements per proporcionar fiabilitat i exigeix certa logística de processament d'errors i gestió d'estat compartida. IKE podria acabar en un estat mort a causa de la manca d'aquestes mesures de fiabilitat, on ambdues parts esperaven que l'altra iniciés una acció, cosa que mai va arribar a succeir. Es van desenvolupar solucions alternatives (com ara la detecció de Dead-Peer-Detection), però no es van estandarditzar. Això significava que les diferents implementacions de solucions alternatives no sempre eren compatibles. Resiliència als atacs de denegació de servei (DoS): IKEv2 no realitza gaire processament fins que determina si el sol·licitant realment existeix. Això va solucionar alguns dels problemes de DoS que patia IKE, que realitzava molts processaments criptogràfics cars des d'ubicacions falsejades.
Si suposem que l'hostA té un índex de paràmetres de seguretat (SPI) d'A i l'hostB té un SPI de B, l'escenari seria així:Si l'HostB (el que respon) experimenta una gran quantitat de connexions IKE mig obertes, enviarà un missatge de resposta sense xifrar IKE_SA_INIT a l'HostA (l'iniciador) amb un missatge de notificació de tipus COOKIE, i esperarà que l'HostA enviï una sol·licitud IKE_SA_INIT amb aquest valor de galeta en una càrrega útil de notificació a l'HostB. Això és per garantir que l'iniciador sigui realment capaç de gestionar una resposta IKE del que respon.
Extensions de protocol El grup de treball ipsecme de l'IETF ha estandarditzat diverses extensions, amb l'objectiu de modernitzar el protocol IKEv2 i adaptar-lo millor a entorns de producció d'alt volum. Aquestes extensions inclouen:
Represa de la sessió IKE: la capacitat de reprendre una "sessió" IKE/IPsec fallida després d'un error, sense necessitat de passar per tot el procés de configuració d'IKE (RFC 5723). Redirecció IKE: redirecció de les sol·licituds IKE entrants, que permet un equilibri de càrrega senzill entre diversos punts finals IKE (RFC 5840). Visibilitat del trànsit IPsec: etiquetatge especial dels paquets ESP que estan autenticats però no xifrats, amb l'objectiu de facilitar que els middleboxes (com ara els sistemes de detecció d'intrusions) puguin analitzar el flux (RFC 5998). Autenticació EAP mútua: suport per a l'autenticació només EAP (és a dir, sense certificat) dels dos iguals IKE; l'objectiu és permetre l'ús de mètodes d'autenticació moderns basats en contrasenya (RFC 5998). Detecció ràpida de fallades: minimitzar el temps fins que un node IKE detecta que el seu node oposat s'ha bloquejat (RFC 6290). Extensions d'alta disponibilitat: millora de la sincronització de protocols a nivell IKE/IPsec entre un clúster de punts finals IPsec i un peer, per reduir la probabilitat de connexions perdudes després d'un esdeveniment de failover (RFC 6311).
Implementacions IKE és compatible com a part de la implementació d'IPsec a Windows 2000, Windows XP, Windows Server 2003, Windows Vista i Windows Server 2008.Internet Key Exchange: Internet Protocol Security (IPsec): Technet La implementació d'ISAKMP/IKE va ser desenvolupada conjuntament per Cisco i Microsoft.
Microsoft Windows 7 i Windows Server 2008 R2 admeten parcialment IKEv2 ((RFC 7296) així com MOBIKE (RFC 4555) a través de la funció VPN Reconnect (també coneguda com a Agile VPN).
Hi ha diverses implementacions de codi obert d'IPsec amb capacitats IKE associades. A Linux, les implementacions de Libreswan, Openswan i strongSwan proporcionen un daemon IKE que pot configurar (és a dir, establir SA) per a les piles d'IPsec basades en el nucli KLIPS o XFRM/NETKEY. XFRM/NETKEY és la implementació nativa d'IPsec de Linux disponible a partir de la versió 2.6.
Les distribucions de programari de Berkeley també implementen el daemon IPsec i IKE a través de l'OpenBSD Cryptographic Framework (OCF), cosa que facilita molt el suport als acceleradors criptogràfics. OCF s'ha portat recentment a Linux.
Diversos proveïdors d'equips de xarxa han creat els seus propis daemons IKE (i implementacions d'IPsec) o bé llicencien una pila els uns dels altres.