Internet Key Exchange

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.[1] 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.[2][3] 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.[2]

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.[4]
  •   RFC 2408 va definir l'Associació de Seguretat d'Internet i Key Management Protocol (ISAKMP).[5]
  •   RFC 2409 va definir el Internet Key Exchange (IKE).[6]

  updated IKE to version two (IKEv2) in December 2005.[7] RFC 4718 clarified some open details in October 2006.[8]   RFC 5996 combined these two documents plus additional clarifications into the updated IKEv2,[9] 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.[10]

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.[11] L'autenticació es pot realitzar mitjançant una clau precompartida (secret compartit), signatures o xifratge de clau pública.[12] 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.[13]

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).[14] La fase 2 només funciona en mode ràpid.[15]

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.[16][17] La resolució de problemes es complicava encara més per la sortida de depuració limitada o críptica en moltes implementacions.[18]

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.[19]

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.[20]
  • 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.[21] La implementació d'ISAKMP/IKE va ser desenvolupada conjuntament per Cisco i Microsoft.[22]



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.



Hi ha diverses implementacions d'IKEv2 i algunes de les empreses que es dediquen a la certificació IPsec i a les proves d'interoperabilitat estan començant a organitzar tallers per a les proves, així com a actualitzar els requisits de certificació per fer front a les proves d'IKEv2.



Les següents implementacions de codi obert d'IKEv2 estan disponibles:



  • OpenIKEv2,[23]
    • 

  • Cigne fort,
    • 

  • Libreswan,
    • 

  • Openswan,
    • 

  • Mapache del projecte KAME,
    • 

  • iked del projecte OpenBSD.[24]



Vulnerabilitats


Presentacions de la NSA filtrades i publicades el 2014 per Der Spiegel indiquen que IKE s'està explotant de manera desconeguda per desxifrar el trànsit IPsec, igual que ISAKMP.[25] Els investigadors que van descobrir l'atac Logjam afirmen que trencar un grup Diffie-Hellman de 1024 bits trencaria el 66% dels servidors VPN, el 18% del milió de dominis HTTPS principals i el 26% dels servidors SSH, cosa que els investigadors afirmen que és coherent amb les filtracions.[26] Aquesta afirmació va ser refutada el 2015 tant per Eyal Ronen com per Adi Shamir en el seu article "Critical Review of Imperfect Forward Secrecy"[27] i per Paul Wouters de Libreswan en un article del 2015 "66% de les VPN no estan de fet trencades".[28]



Les configuracions de VPN IPsec que permeten la negociació de múltiples configuracions estan subjectes a atacs de degradació basats en MITM entre les configuracions ofertes, tant amb IKEv1 com amb IKEv2.[29] Això es pot evitar mitjançant una segregació acurada dels sistemes client en múltiples punts d'accés al servei amb configuracions més estrictes.



Ambdues versions de l'estàndard IKE són susceptibles a un atac de diccionari fora de línia quan s'utilitza una contrasenya de baixa entropia. Per a l'IKEv1, això és cert tant per al mode principal com per al mode agressiu.[30][31][32]



Referències




  1. ↑ The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
    2. 

  2. 1 2 Thomas, M. (June 2001), RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, p. 1, doi:10.17487/RFC3129, <http://tools.ietf.org/html/rfc3129>
    3. 

  3. ↑ Richardson, M. (June 2001), RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE), Internet Engineering Task Force, p. 5, doi:10.17487/RFC4322, <http://tools.ietf.org/html/rfc4322>
    4. 

  4. ↑ The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, doi:10.17487/RFC2407, <https://datatracker.ietf.org/doc/html/rfc2407>
    5. 

  5. ↑ Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, doi:10.17487/RFC2408, <https://datatracker.ietf.org/doc/html/rfc2408>
    6. 

  6. ↑ D. Harkins, The Internet Key Exchange (IKE), RFC 2409, doi:10.17487/RFC2409, <https://datatracker.ietf.org/doc/html/rfc2409>
    7. 

  7. ↑ C. Kaufman (Microsoft) (December 2005), Internet Key Exchange (IKEv2) Protocol, RFC 4306, doi:10.17487/RFC4306, <https://datatracker.ietf.org/doc/html/rfc4306>
    8. 

  8. ↑ Eronen, P. & Hoffman, P. (October 2006), IKEv2 Clarifications and Implementation Guidelines, RFC 4718, doi:10.17487/RFC4718, <https://datatracker.ietf.org/doc/html/rfc4718>
    9. 

  9. ↑ Kaufman, C.; Hoffman, P. & Nir, Y. et al. (September 2010), Internet Key Exchange (IKEv2) Protocol, RFC 5996, doi:10.17487/RFC5996, <https://datatracker.ietf.org/doc/html/rfc5996>
    10. 

  10. ↑ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
    11. 

  11. ↑ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 6
    12. 

  12. ↑ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 10-16
    13. 

  13. ↑ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
    14. 

  14. ↑ "RFC 4306 Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p. 11,33
    15. 

  15. ↑ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
    16. 

  16. ↑ IPsec Phase 1 Configuration, Netgate Documentation, <https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p1.html>. Consulta: 7 agost 2025
    17. 

  17. ↑ IPsec VPN Interoperability, Libreswan Project, <https://libreswan.org/wiki/Interoperability>. Consulta: 7 agost 2025
    18. 

  18. ↑ NSX-T IPsec VPN Troubleshooting, Broadcom TechDocs, <https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-2/administration-guide/virtual-private-network-vpn/troubleshooting-vpn-issues-in-nsx-t-data-center/alarms-when-an-ipsec-vpn-session-is-down.html>. Consulta: 7 agost 2025
    19. 

  19. ↑ Understanding Dead Peer Detection, Palo Alto Networks Knowledge Base, <https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000oMqxCAE>. Consulta: 7 agost 2025
    20. 

  20. ↑ "RFC 4306: Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p 38-40
    21. 

  21. ↑ Internet Key Exchange: Internet Protocol Security (IPsec): Technet
    22. 

  22. ↑ «Using IPSec in Windows 2000 and XP, Part 1» (en anglès). Arxivat de l'original el 2008-10-12. [Consulta: 24 desembre 2009].
    23. 

  23. ↑ «OpenIKEv2» (en anglès). GitHub. [Consulta: 21 juny 2023].
    24. 

  24. ↑ «iked(8) - OpenBSD manual pages» (en anglès). man.openbsd.org. [Consulta: 21 juny 2023].
    25. 

  25. ↑ Fielded Capability: End-to-end VPN SPIN9 Design Review, <http://www.spiegel.de/media/media-35529.pdf>
    26. 

  26. ↑  (October 2015) "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" a 22nd ACM Conference on Computer and Communications Security (CCS ’15).  
    27. 

  27. ↑ Ronen, Eyal. «Critical Review of Imperfect Forward Secrecy» (en anglès), 01-10-2015.
    28. 

  28. ↑ Wouters, Paul. «66% of VPN's are not in fact broken» (en anglès), 01-10-2015.
    29. 

  29. ↑ Bhargavan, Karthikeyan. «Downgrade Resilience in Key-Exchange Protocols» (en anglès), 01-01-2016.
    30. 

  30. ↑ Pliam, John. «Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets» (en anglès). Johns Hopkins University, 2 octubre 1999. Arxivat de l'original el 10 June 2002. [Consulta: 5 febrer 2020].
    31. 

  31. ↑ McGrew, David. «Great Cipher, But Where Did You Get That Key» (en anglès). Cisco Blog, 05-07-2011. Arxivat de l'original el 9 July 2011. [Consulta: 11 febrer 2020].
    32. 

  32. ↑ Felsch, Dennis. The Dangers of Key Reuse: Practical Attacks on IPsec IKE (en anglès), August 2018. ISBN 9781939133045.
    33. 






    This article is issued from Viquipèdia. The text is available under Creative Commons Attribution-Share Alike 4.0 unless otherwise noted. Additional terms may apply for the media files.