IPsec

IPsec
IPsec (abreviatura de Internet Protocol security) es un conjunto de protocolos cuya funcin es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos. IPsec tambin incluye protocolos para el establecimiento de claves de cifrado.

Resumen
Los protocolos de IPsec actan en la capa de red, la capa 3 del modelo OSI. Otros protocolos de seguridad para Internet de uso extendido, como SSL, TLS y SSH operan de la capa de transporte (capa 4 del modelo OSI) hacia arriba. Esto hace que IPsec sea ms flexible, ya que puede ser utilizado para proteger protocolos de la capa 4, incluyendo TCP y UDP, los protocolos de capa de transporte ms usados. Una ventaja importante de IPsec frente a SSL y otros mtodos que operan en capas superiores, es que para que una aplicacin pueda usar IPsec no hay que hacer ningn cambio, mientras que para usar SSL y otros protocolos de niveles superiores, las aplicaciones tienen que modificar su cdigo.

Arquitectura de seguridad
IPsec est implementado por un conjunto de protocolos criptogrficos para (1) asegurar el flujo de paquetes, (2) garantizar la autenticacin mutua y (3) establecer parmetros criptogrficos. La arquitectura de seguridad IP utiliza el concepto de asociacin de seguridad (SA) como base para construir funciones de seguridad en IP. Una asociacin de seguridad es simplemente el paquete de algoritmos y parmetros (tales como las claves) que se est usando para cifrar y autenticar un flujo particular en una direccin. Por lo tanto, en el trfico normal bidireccional, los flujos son asegurados por un par de asociaciones de seguridad. La decisin final de los algoritmos de cifrado y autenticacin (de una lista definida) le corresponde al administrador de IPsec. Para decidir qu proteccin se va a proporcionar a un paquete saliente, IPsec utiliza el ndice de parmetro de seguridad (SPI), un ndice a la base de datos de asociaciones de seguridad (SADB), junto con la direccin de destino de la cabecera del paquete, que juntos identifican de forma nica una asociacin de seguridad para dicho paquete. Para un paquete entrante se realiza un procedimiento similar; en este caso IPsec toma las claves de verificacin y descifrado de la base de datos de asociaciones de seguridad. En el caso de multicast, se proporciona una asociacin de seguridad al grupo, y se duplica para todos los receptores autorizados del grupo. Puede haber ms de una asociacin de seguridad para un grupo, utilizando diferentes SPIs, y por ello permitiendo mltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener mltiples asociaciones de seguridad, permitiendo autenticacin, ya que un receptor slo puede saber que alguien que conoce las claves ha enviado los datos. Hay que observar que el estndar pertinente no describe cmo se elige y duplica la asociacin a travs del grupo; se asume que un interesado responsable habr hecho la eleccin..

Estado actual del estndar

IPsec es una parte obligatoria de IPv6, y su uso es opcional con IPv4. Aunque el estndar est diseado para ser indiferente a las versiones de IP, el despliegue y experiencia hasta 2007 atae a las implementaciones de IPv4. Los protocolos de IPsec se definieron originalmente en las RFCs 1825 y 1829, publicadas en 1995. En 1998 estos documentos fueron sustituidos por las RFCs 2401 y 2412, que no son compatibles con la 1825 y 1829, aunque son conceptualmente idnticas. En diciembre de 2005 se produjo la tercera generacin de documentos, RFCs 4301 y 4309. Son en gran parte un superconjunto de la 2401 y 2412, pero proporcionan un segundo estndar de Internet Key Exchange. Esta tercera generacin de documentos estandariz la abreviatura de IPsec como "IP" en maysculas y "sec" en minsculas.

IPsec Es raro ver un producto que ofrezca soporte de RFC1825 y 1829. "ESP" se refiere generalmente a 2406, mientras que ESPbis se refiere a 4303.

Propsito de diseo
IPsec fue proyectado para proporcionar seguridad en modo transporte (extremo a extremo) del trfico de paquetes, en el que los ordenadores de los extremos finales realizan el procesado de seguridad, o en modo tnel (puerta a puerta) en el que la seguridad del trfico de paquetes es proporcionada a varias mquinas (incluso a toda la red de rea local) por un nico nodo. IPsec puede utilizarse para crear VPNs en los dos modos, y este es su uso principal. Hay que tener en cuenta, sin embargo, que las implicaciones de seguridad son bastante diferentes entre los dos modos de operacin. La seguridad de comunicaciones extremo a extremo a escala Internet se ha desarrollado ms lentamente de lo esperado. Parte de la razn a esto es que no ha surgido infraestructura de clave pblica universal o universalmente de confianza (DNSSEC fue originalmente previsto para esto); otra parte es que muchos usuarios no comprenden lo suficientemente bien ni sus necesidades ni las opciones disponibles como para promover su inclusin en los productos de los vendedores. Como el Protocolo de Internet no provee intrnsecamente de ninguna capacidad de seguridad, IPsec se introdujo para proporcionar servicios de seguridad tales como: 1. 2. 3. 4. Cifrar el trfico (de forma que no pueda ser ledo por nadie ms que las partes a las que est dirigido) Validacin de integridad (asegurar que el trfico no ha sido modificado a lo largo de su trayecto) Autenticar a los extremos (asegurar que el trfico proviene de un extremo de confianza) Anti-repeticin (proteger contra la repeticin de la sesin segura).

Modos
As pues y dependiendo del nivel sobre el que se acte, podemos establecer dos modos bsicos de operacin de IPsec: modo transporte y modo tnel.

Modo transporte
En modo transporte, slo la carga til (los datos que se transfieren) del paquete IP es cifrada o autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra la cabecera IP; sin embargo, cuando se utiliza la cabecera de autenticacin (AH), las direcciones IP no pueden ser traducidas, ya que eso invalidara el hash. Las capas de transporte y aplicacin estn siempre aseguradas por un hash, de forma que no pueden ser modificadas de ninguna manera (por ejemplo traduciendo los nmeros de puerto TCP y UDP). El modo transporte se utiliza para comunicaciones ordenador a ordenador. Una forma de encapsular mensajes IPsec para atravesar NAT ha sido definido por RFCs que describen el mecanismo de NAT transversal.

IPsec

Modo tnel
En el modo tnel, todo el paquete IP (datos ms cabeceras del mensaje) es cifrado o autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. El modo tnel se utiliza para comunicaciones red a red (tneles seguros entre routers, p.e. para VPNs) o comunicaciones ordenador a red u ordenador a ordenador sobre Internet.

Protocolos
IPsec consta de dos protocolos que han sido desarrollados para proporcionar seguridad a nivel de paquete, tanto para IPv4 como para IPv6: Authentication Header (AH) proporciona integridad, autenticacin y no repudio si se eligen los algoritmos criptogrficos apropiados. Encapsulating Security Payload (ESP) proporciona confidencialidad y la opcin -altamente recomendable- de autenticacin y proteccin de integridad. Los algoritmos criptogrficos definidos para usar con IPsec incluyen HMAC- SHA-1 para proteccin de integridad, y Triple DES-CBC y AES-CBC para confidencialidad. Ms detalles en la RFC 4305.

Authentication Header (AH)

AH est dirigido a garantizar integridad, sin conexin y autenticacin de los datos de origen de los datagramas IP. Para ello, calcula un Hash Message Authentication Code (HMAC) a travs de algn algoritmo hash operando sobre una clave secreta, el contenido del paquete IP y las partes inmutables del datagrama. Este proceso restringe la posibilidad de emplear NAT, que puede ser implementada con NAT transversal. Por otro lado, AH puede proteger opcionalmente contra ataques de repeticin utilizando la tcnica de ventana deslizante y descartando paquetes viejos. AH protege la carga til IP y todos los campos de la cabecera de un datagrama IP excepto los campos mutantes, es decir, aquellos que pueden ser alterados en el trnsito. En IPv4, los campos de la cabecera IP mutantes (y por lo tanto no autenticados) incluyen TOS, Flags, Offset de fragmentos, TTL y suma de verificacin de la cabecera. AH opera directamente por encima de IP, utilizando el protocolo IP nmero 51. Una cabecera AH mide 32 bits, he aqu un diagrama de cmo se organizan:
0 - 7 bit 8 - 15 bit 16 - 23 bit 24 - 31 bit RESERVED

Next header Payload length

Security parameters index (SPI) Sequence number Hash Message Authentication Code (variable)

Significado de los campos: Next header Identifica el protocolo de los datos transferidos. Payload length Tamao del paquete AH. RESERVED Reservado para uso futuro (hasta entonces todo ceros). Security parameters index (SPI) Indica los parmetros de seguridad que, en combinacin con la direccin IP, identifican la asociacin de seguridad implementada con este paquete.

IPsec Sequence number Un nmero siempre creciente, utilizado para evitar ataques de repeticin. HMAC Contiene el valor de verificacin de integridad (ICV) necesario para autenticar el paquete; puede contener relleno.

Encapsulating Security Payload (ESP)

El protocolo ESP proporciona autenticidad de origen, integridad y proteccin de confidencialidad de un paquete. ESP tambin soporta configuraciones de slo cifrado y slo autenticacin, pero utilizar cifrado sin autenticacin est altamente desaconsejado porque es inseguro[1][2] .[3] Al contrario que con AH, la cabecera del paquete IP no est protegida por ESP (aunque en ESP en modo tnel, la proteccin es proporcionada a todo el paquete IP interno, incluyendo la cabecera interna; la cabecera externa permanece sin proteger). ESP opera directamente sobre IP, utilizando el protocolo IP nmero 50. Un diagrama de paquete ESP:
0 - 7 bit 8 - 15 bit 16 - 23 bit 24 - 31 bit

Security parameters index (SPI) Sequence number Payload data (variable) Padding (0-255 bytes) Pad Length Next Header Authentication Data (variable)

Significado de los campos Security parameters index (SPI) Identifica los parmetros de seguridad en combinacin con la direccin IP. Sequence number Un nmero siempre creciente, utilizado para evitar ataques de repeticin. Payload data Los datos a transferir. Padding Usado por algunos algoritmos criptogrficos para rellenar por completo los bloques. Pad length Tamao del relleno en bytes. Next header Identifica el protocolo de los datos transferidos. Authentication data Contiene los datos utilizados para autenticar el paquete.

IPsec

Implementaciones
El soporte de IPsec est normalmente implementado en el ncleo con la gestin de claves y negociacin de ISAKMP/IKE realizada en espacio de usuario. Las implementaciones de IPsec existentes suelen incluir ambas funcionalidades. Sin embargo, como hay un interfaz estndar para la gestin de claves, es posible controlar una pila IPsec de ncleo utilizando las herramientas de gestin de claves de una implementacin distinta. Por esta razn, hay confusin en los orgenes de la implementacin de IPsec que se encuentra en el ncleo Linux. El proyecto FreeS/WAN realiz la primera implementacin completa y de cdigo abierto de IPsec para Linux. Consiste en una pila IPsec de ncleo KLIPS, junto con un demonio (pluto) y muchos scripts de shell. El proyecto FreeS/WAN fue desmantelado en marzo de 2004. Openswan y strongSwan son continuaciones de FreeS/WAN. El proyecto KAME tambin implement soporte IPsec completo para NetBSD y FreeBSD. Su demonio de gestin de claves se llama racoon. OpenBSD hizo su propio demonio ISAKMP/IKE, llamado simplemente isakmpd (y ha sido portado a otros sistemas, incluyendo Linux). Sin embargo, ninguna de estas pilas IPsec de ncleo estaba integrada en Linux. Alexey Kuznetsov y David S. Miller escribieron desde cero una implementacin de IPsec de ncleo para Linux alrededor de finales de 2002. Esta pila fue posteriormente lanzada como parte de Linux 2.6, y es llamada por varios "nativa"o "NETKEY". Por lo tanto, contrariamente a la creencia popular, la pila IPsec de Linux no se origin en el proyecto KAME. Como soporta el protocolo estndar PF KEY (RFC 2368) y el intefaz nativo XFRM para gestin de claves, la pila IPsec de Linux puede utilizarse junto con pluto de Openswan/strongSwan, isakmpd del proyecto OpenBSD, racoon del proyecto KAME o sin ningn demonio ISAKMP/IKE (utilizando claves manuales). Las nuevas arquitecturas de procesadores de red, incluyendo procesadores multincleo con motores de cifrado integrados, han cambiado la forma en que las pilas IPsec son diseadas. Un Fast Path dedicado es utilizado para descargar el procesado de las tareas de IPsec (SA, bsquedas SP, cifrado, etc). Estas pilas Fast Path deben estar cointegradas en ncleos dedicados con Linux o RTOS corriendo en otros ncleos. Estos SO son el plano de control que ejecuta ISAKMP/IKE de la pila IPsec Fast Path. Hay bastantes implementaciones de los protocolos IPsec e ISAKMP/IKE. Entre otras: 6WINDGate [4], pila IPsec Fast Path para procesador de red multincleo NRL [5] IPsec, una de las fuentes originales de cdigo IPsec [6] OpenBSD, con su propio cdigo derivado de NRL IPsec La pila de KAME, que est incluida en Mac OS X, NetBSD y FreeBSD "IPsec" en el software IOS de Cisco [7] "IPsec" en Microsoft Windows, incluyendo Windows XP[8] [9], Windows 2000[10], y Windows 2003[11] Las herramientas QuickSec de SafeNet [12] IPsec en Solaris [13] El sistema operativo AIX de IBM z/OS de IBM IPsec e IKE en HP-UX (HP-UX IPSec) "IPsec e IKE" en VxWorks [14]

IPsec

Lista de RFCs relacionados con IPsec

RFC 2327: PF_KEY Interface RFC 2367: PF_KEY Interface RFC 2401 (sustituye a RFC 1825 y fue sustituida por RFC 4301): Security Architecture for the Internet Protocol RFC 2402 (sustituida por RFC 4302 y RFC 4305): Authentication Header RFC 2403: The Use of HMAC-MD5-96 within ESP and AH RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV RFC 2406 (sustituida por RFC 4303 y RFC 4305): Encapsulating Security Payload RFC 2407 (sustituida por RFC 4306): IPsec Domain of Interpretation for ISAKMP (IPsec DoI) RFC 2408 (sustituida por RFC 4306): Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409 (sustituida por RFC 4306): Internet Key Exchange (IKE) RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec RFC 2411: IP Security Document Roadmap RFC 2412: (sustituye a RFC 1829) The OAKLEY Key Determination Protocol RFC 2451: The ESP CBC-Mode Cipher Algorithms RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements RFC 3947: Negotiation of NAT-Traversal in the IKE RFC 3948: UDP Encapsulation of IPsec ESP Packets RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) RFC 4301 (sustituye a RFC 2401): Security Architecture for the Internet Protocol RFC 4302 (sustituye a RFC 2402): IP Authentication Header RFC 4303 (sustituye a RFC 2406): IP Encapsulating Security Payload (ESP) RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) RFC 4305 (sustituida por RFC 4835): Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) RFC 4306 (sustituye a RFC 2407, RFC 2408, and RFC 2409): Internet Key Exchange (IKEv2) Protocol RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) RFC 4308: Cryptographic Suites for IPsec RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE) RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol RFC 4718: IKEv2 Clarifications and Implementation Guidelines RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2 RFC 4809: Requirements for an IPsec Certificate Management Profile RFC 4835 (sustituye a RFC 4305): Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX

IPsec

Referencias
[4] http:/ / www. 6wind. com/ 6WINDGate-software. html [5] http:/ / www. itd. nrl. navy. mil/ [6] http:/ / ezine. daemonnews. org/ 199812/ security. html [7] http:/ / www. cisco. com/ en/ US/ tech/ tk583/ tk372/ technologies_tech_note09186a0080094203. shtml [8] http:/ / support. microsoft. com/ ?kbid=884909 [9] http:/ / support. microsoft. com/ kb/ 818043/ [10] http:/ / www. microsoft. com/ windows2000/ technologies/ communications/ ipsec/ default. mspx [11] http:/ / www. microsoft. com/ windowsserver2003/ technologies/ networking/ ipsec/ default. mspx [12] http:/ / www. safenet-inc. com/ products/ swTK/ index. asp [13] http:/ / docs. sun. com/ app/ docs/ doc/ 817-2694?a=expand [14] http:/ / www. windriver. com/ portal/ server. pt?space=CommunityPage& cached=true& control=SetCommunity& CommunityID=766

Fuentes y contribuyentes del artculo

Fuentes y contribuyentes del artculo

IPsec Fuente: http://es.wikipedia.org/w/index.php?oldid=64463130 Contribuyentes: Barri, Caos, Caritdf, ColdWind, Corund, Damifb, Equi, Garaizar, GermanX, Gus2710, Jgaray, Leonpolanco, Libertad y Saber, Lordsito, Loxza, Martini 001, Mr.Ajedrez, Niqueco, Oscar ., PabloCastellano, Pacebes, Pedro Del Gallego, QuirogaXD, Shooke, Uooopaa, Urik, 76 ediciones annimas

Licencia
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/