Grupo de Trabajo en Red D. Maughan Request for Comments: 2408 National Security Agency Categoría: Pila de estándares M. Schertler Securify, Inc. M. Schneider National Security Agency J. Turner RABA Technologies, Inc. Noviembre 1998 Traducción al castellano: Agosto 2005 Hugo Adrian Francisconi Protocolo de Gestión de Claves y Asociaciones de Seguridad en Internet (ISAKMP) Estado de este documento Este documento especifica un protocolo de Internet en vías de estandarización para la comunidad de Internet y solicita debate y sugerencias para mejorarlo. Por favor, remítase a la edición actual de "Estándares de Protocolos Oficiales de Internet" (STD 1) para conocer el estado de estandarización y status de este protocolo. La distribución de este memorándum es ilimitada. Aviso de Copyright Copyright (c) Sociedad Internet (1998). Todos los derechos reservados. Resumen Este documento describe un protocolo que utiliza conceptos de seguridad necesarios para el establecimiento de Asociaciones de Seguridad (SA) y claves criptográficas en un entorno de Internet. Un protocolo que negocia, establece, modifica y cancela SAs y sus atributos es requerido para la Internet en desarrollo, donde existirán numerosos mecanismos de seguridad y varias opciones para cada mecanismo. El protocolo de seguridad de manejo de claves debe ser robusto para manejar la generación de claves públicas para la comunidad de Internet y los requerimientos de claves privadas para esas redes privadas con ese requerimiento. El Protocolo para el manejo de claves y Asociaciones de Seguridad (ISAKMP) define los procedimientos para autentificar comunicaciones entre usuarios, la Maughan, et. al. Pila de Estándares [Pág. 1] RFC 2408 ISAKMP Noviembre 1998 creación y administración de Asociaciones de Seguridad, las técnicas de generación de claves y atenuación de amenazas (como por ejemplo, denegación de servicio y ataques de reenvío). Todo esto es necesario para entablar y mantener comunicaciones seguras (A través de los servicios de seguridad IP o cualquier otro protocolo de seguridad) en un entorno de Internet. Lista de contenido 1. Introducción........................................................4 1.1 Requisitos Terminológicos.......................................6 1.2 La Necesidad de Negociación.....................................6 1.3 Que Puede Ser Negociado.........................................6 1.4 Asociaciones de Seguridad y Administración......................7 1.4.1 Asociaciones de Seguridad y Registraciones.................8 1.4.2 Requisitos de ISAKMP.......................................8 1.5 Autentificación.................................................9 1.5.1 Autoridades de Certificación...............................9 1.5.2. Nombramiento de la Entidad...............................10 1.5.3 Requerimientos de ISAKMP..................................10 1.6 Criptografía de Clave Pública..................................11 1.6.1 Propiedades del Intercambio de Claves.....................12 1.6.2 Requisitos para ISAKMP....................................13 1.7 Protección ISAKMP...........................................13 1.7.1 Anti-Saturación (Denegación de Servicio)..................13 1.7.2 Secuestro de la Conexión..................................14 1.7.3 Ataques en la Trayectoria (Man-in-the-Middle Attacks).....14 1.8 Comunicaciones Multicast.......................................15 2. Conceptos y Terminología...........................................15 2.1 Terminología de ISAKMP.........................................15 2.2 Ubicación de ISAKMP............................................17 2.3 Fases de la Negociación........................................18 2.4 Identificar SA.................................................19 2.5 Temas Diversos.................................................22 2.5.1 Protocolo de Trasporte....................................22 2.5.2 Campos RESERVADOS.........................................22 2.5.3 Creación de Token ("Cookies") Anti-Saturación.............22 3 Cargas de ISAKMP....................................................23 3.1 Formato de la Cabecera de ISAKMP..............................23 3.2 Cabecera de Carga Genérica....................................28 3.3 Atributos de los Datos........................................28 3.4 Carga SA......................................................29 3.5 Carga de la Propuesta.........................................31 3.6 Carga de Transformación.......................................32 3.7 Carga de Intercambio de claves................................34 3.8 Carga de Identificación.......................................35 3.9 Carga de Certificado..........................................36 3.10 Carga de Solicitud de Certificado.............................37 Maughan, et. al. Pila de Estándares [Pág. 2] RFC 2408 ISAKMP Noviembre 1998 3.11 Carga Hash....................................................38 3.12 Carga de la Firma.............................................39 3.13 Carga Nonce...................................................40 3.14 Carga de Notificación.........................................41 3.14.1 Tipos de Mensaje de Notificación.........................43 3.15 Carga de Cancelación..........................................45 3.16 Carga de Identificador del vendedor...........................46 4 Intercambios ISAKMP.................................................48 4.1 Tipos de Intercambios ISAKMP...................................48 4.1.1 Notación.....................................................50 4.2 Establecimiento de Asociaciones de Seguridad...................50 4.2.1 Ejemplos de Establecimientos de Asociaciones de Seguridad.52 4.3 Modificación de Asociaciones de Seguridad......................56 4.4 Intercambio Base...............................................56 4.5 Intercambio de Protección de Identidad.........................58 4.6 Intercambio de Solamente Autentificación.......................59 4.7 Intercambio Agresivo...........................................61 4.8 Intercambio Informativo........................................62 5 Procesamiento de la Carga ISAKMP....................................63 5.1 Procesamiento General del Mensaje.............................63 5.2 Procesamiento de la Cabecera ISAKMP...........................64 5.3 Procesamiento de la Cabecera de Carga Genérica................66 5.4 Procesamiento de la Carga SA..................................67 5.5 Procesamiento de la Carga de la Propuesta.....................68 5.6 Procesamiento de la Carga de Transformación...................70 5.7 Procesamiento de la Carga de Intercambio de Claves............71 5.8 Procesamiento de la Carga de Identificación...................72 5.9 Procesamiento de la Carga de Certificado......................72 5.10 Procesamiento de la Carga de Solicitud de Certificado.........73 5.11 Procesamiento de la Carga Hash................................75 5.12 Procesamiento de la Carga de la Firma.........................76 5.13 Procesamiento de la Carga Nonce...............................77 5.14 Procesamiento de la Carga de Notificación.....................77 5.15 Procesamiento de la Carga de Cancelación......................79 6 Conclusiones........................................................81 A Atributos de una Asociación de Seguridad ISAKMP.....................83 A.1 Antecedentes/Fundamentos.......................................83 A.2 Valor Asignado al DOI de Seguridad IP en Internet..............83 A.3 Protocolos de Seguridad Soportados.............................83 A.4 Valores del Tipo de Identificación de ISAKMP...................84 A.4.1 Identificador de Dirección IPv4...........................84 A.4.2 Identificador de Dirección de Subred IPv4.................84 A.4.3 Identificador de Dirección IPv6...........................84 A.4.4 Identificador de Dirección de Subred IPv6.................84 B Definición de un Nuevo Dominio de Interpretación....................85 B.1 Situación......................................................85 B.2 Políticas de Seguridad.........................................86 B.3 Esquemas de Nombramiento.......................................86 Maughan, et. al. Pila de Estándares [Pág. 3] RFC 2408 ISAKMP Noviembre 1998 B.4 Sintaxis Para la Especificación de Servicios de Seguridad......86 B.5 Especificación de Carga........................................86 B.6 Definición de Nuevos Tipos de Intercambio......................86 Consideraciones de Seguridad..........................................88 Consideraciones de IANA...............................................88 Dominio de Interpretación.............................................88 Protocolos de Seguridad Soportados....................................89 Agradecimientos.......................................................89 Referencias...........................................................89 Direcciones de los Autores............................................92 Declaración de Copyright Completa.....................................93 Notas del Traductor...................................................94 Derechos de Copyright Sobre Esta Traducción...........................95 Datos del Traductor...................................................95 Lista de Imágenes 1 Ubicación de ISAKMP................................................18 2 Formato de la Cabecera ISAKMP......................................24 3 Cabecera de Carga Genérica.........................................28 4 Formato de los Atributos de los Datos..............................29 5 Formato de la Carga SA.............................................30 6 Formato de la Carga de la Propuesta................................31 7 Transformación de la Carga.........................................33 8 Formato de la Carga de Intercambio de Claves.......................34 9 Formato de la carga de Identificación..............................35 10 Formato de la Carga de Certificado.................................36 11 Formato de la Carga de Solicitud de Certificado....................38 12 Formato de la carga Hash...........................................39 13 Formato de la Carga de la Firma....................................40 14 Formato de la Carga de Nonce.......................................41 15 Formato de la Carga de Notificación................................42 16 Formato de la Carga de Cancelación.................................45 17 Formato de la Carga de Identificador del Vendedor..................48 1 Introducción Este documento describe el Protocolo de Gestión de Claves y Asociaciones de Seguridad en Internet (ISAKMP). ISAKMP combina los conceptos de seguridad de autentificación, administración de claves, y de asociaciones de seguridad para establecer la seguridad requerida por el gobierno, comercio, y comunicaciones privadas en Internet. El Protocolo de Gestión de Claves y Asociaciones de Seguridad en Internet (ISAKMP) define los procedimientos y los formatos de los paquetes para establecer, negociar, modificar y eliminar las Maughan, et. al. Pila de Estándares [Pág. 4] RFC 2408 ISAKMP Noviembre 1998 Asociaciones de Seguridad (SA). Las SAs contienen toda la información requerida para la ejecución de varios servicios de seguridad de red, tales como los servicios de la capa IP (tales como la cabecera de autentificación y la cabecera de carga de seguridad encapsulada), trasporte o servicios de la capa aplicación o autoprotección del tráfico de negociación. ISAKMP define las cargas para el intercambio de generación de claves y autentificación de datos. Estos formatos proporcionan un marco consistente para la transferencia de claves y autentificación de datos que es independiente de la técnica de generación de claves algoritmo de encriptación, y mecanismo de autentificación. ISAKMP es diferente al protocolo de intercambio de claves para separar claramente los detalles de la administración de SA (y administración de claves) de los detalles de intercambio de claves. Puede haber diferentes protocolos de intercambio de claves, cada uno con propiedades de seguridad diferente. Sin embargo, un marco común es requerido para acordar el formato de los atributos de la SA, y para la negociación, modificación, y cancelación de SAs. ISAKMP proporciona este marco común. La separación de la funcionalidad en tres partes agrega complejidad al análisis de seguridad a una implementación de ISAKMP completa. No obstante, la separación es importante para la interoperatibilidad entre sistemas con requerimientos de seguridad diferentes, y debería también simplificar el análisis de una futura evolución de un servidor ISAKMP. ISAKMP está diseñado para soportar la negociación de SAs de los protocolos de seguridad de todas las capas de la pila de protocolos de red (IPsec, TLS, TLSP, OSPF, etc.). Centralizando la administración de SAs, ISAKMP reduce el costo de la funcionalidad duplicada dentro de cada protocolo de seguridad. ISAKMP también puede reducir el tiempo de inicio de conexión, negociando un conjunto de servicios al mismo tiempo. El resto de la sección 1 establece la motivación para la negociación de seguridad y detalla los componentes principales de ISAKMP, es decir SA y administración, autentificación, criptografía de clave pública y otros temas relacionados. La Sección 2 presenta la terminología y los conceptos relacionados con ISAKMP. La Sección 3 describe los diferentes formatos de carga ISAKMP. La Sección 4 describe como están compuestas las cargas ISAKMP y los tipos de intercambios para establecer SAs y realizar intercambios de claves en un modo autentificado. La modificación, cancelación, y notificación de error de una SA, son también analizados en esa sección. La Sección 5 describe el procesamiento de cada carga dentro del contexto de los intercambios de ISAKMP, incluyendo el manejo de errores y temas Maughan, et. al. Pila de Estándares [Pág. 5] RFC 2408 ISAKMP Noviembre 1998 relacionados. Los apéndices proporcionan los valores de los atributos, necesarios para ISAKMP y los requisitos para definir un nuevo Dominio de Interpretación (DOI) dentro de ISAKMP. 1.1 Requisitos Terminológicos Las palabras DEBE, NO DEBE, REQUERIDO, PODER, NO PODER, DEBERÍA, NO DEBERÍA, RECOMENDADO, PUEDE y OPCIONAL, cuando aparezcan en este documento, deben interpretarse como se describen en [RFC-2119]. 1.2 La Necesidad de Negociación ISAKMP extiende la aseveración de [DOW92] en que la autentificación y los intercambios de claves deben ser combinados para mejorar la seguridad incluida en los intercambios de SA. Los servicios de seguridad requeridos para las comunicaciones dependen de la configuración de las redes individuales y del ambiente. Las organizaciones que forman Redes Privadas Virtuales (VPN), también conocidas como Intranet, necesitarán un conjunto de funciones de seguridad para las comunicaciones dentro de las VPN y posiblemente muchas funciones de seguridad diferentes para comunicaciones fuera de las VPN, para soportar geográficamente componentes organizativos separados, clientes, proveedores, subcontratistas (con sus propias VPNs), gobiernos, y otros. Los departamentos dentro de las grandes organizaciones requerirán un número de SA para separar y proteger los datos (por ejemplo, datos personales, datos de la compañía, etc.) en redes internas y en otras SAs para comunicarse dentro del mismo departamento. Usuarios móviles que quieren "llamar a casa" representan otro conjunto de requerimientos de seguridad. Estos requerimientos deben ser condicionados con un ancho de banda. Entidades más pequeñas pueden resolver sus requisitos de seguridad estableciendo "redes de confianza". Los intercambios de ISAKMP proporcionan a estas comunidades de red la capacidad de presentar usuarios con funciones de seguridad que el usuario soporta en un modo acordado, autentificado y protegido sobre un conjunto de atributos de seguridad en común, es decir una, SA ínter operable. 1.3 Qué Puede ser Negociado Las Asociaciones de Seguridad deben soportar diversos algoritmos de encriptación, mecanismos de autentificación y algoritmos para el establecimiento de claves, para otros protocolos de seguridad, como así también para IPsec. Las Asociaciones de seguridad también deben soportar certificados orientados a host para los protocolos de capas inferiores y certificados orientados a usuarios para protocolos de capas superiores. Algoritmos y mecanismos independientes se requieren en aplicaciones tales como, e-mail, conexión remota, transferencia de Maughan, et. al. Pila de Estándares [Pág. 6] RFC 2408 ISAKMP Noviembre 1998 archivos, como así también sesiones orientadas a protocolos, protocolos de ruteo, y protocolos de capas de enlace. ISAKMP proporciona una SA común y protocolos de establecimiento de claves para esta gran variedad de protocolos de seguridad, aplicaciones, requerimientos de seguridad y ambientes de redes. ISAKMP no está sujeto a ningún algoritmo criptográfico especifico, técnica de generación de claves o mecanismos de seguridad. Esta flexibilidad es beneficiosa por numerosas razones. Primero porque soporta ambientes de comunicaciones dinámicos descriptos anteriormente. Segundo independencia de los mecanismos de seguridad específicos y suministra a los algoritmos un mejor camino migratorio progresivo para mecanismos y algoritmos. Cuando mejores mecanismos de seguridad son desarrollados o nuevos ataques a algoritmos de encriptación actuales, mecanismos de autentificación o intercambios de generación de claves son descubiertos ISAKMP permitirá la actualización de algoritmos y mecanismos sin tener que desarrollar un nuevo KMP o mejorar el actual. ISAKMP tiene requisitos básicos para su autentificación y componentes de intercambio de claves. Estos requerimientos protegen contra la denegación de servicio, el reenvío/reflexión, ataques en la trayectoria (man-in-the-middle), y ataques contra secuestro de la conexión. Esto es importante porque estos son los tipos de ataques que están dirigidos hacia los protocolos. El completo soporte de Asociaciones de Seguridad (SA), el cual proporciona mecanismos y algoritmos independientes, y protección de los protocolos contra amenazas son las fortalezas de ISAKMP. 1.4 Asociaciones de Seguridad y Administración Una SA es una relación entre dos o más entidades que describe como las entidades utilizan los servicios de seguridad para comunicarse en forma segura. Esta relación esta representada por un conjunto de información que puede ser considerada como un contrato entre las entidades. La información debe ser acordada y compartida por todas las entidades. Algunas veces solo la información es referida como una SA pero esto es una ejemplificación física de la relación existente. La existencia de esta relación, representada por la información, es lo que proporciona la información de seguridad necesaria para que ínter-operen de forma segura. Todas las entidades se deben adherir a la SA para que sean posibles las comunicaciones seguras. Cuando atributos de SA se accesan, las entidades usan un puntero o un identificador que hace referencia a un SPI. [SEC-ARCH] proporciona detalles referentes a las definiciones de SA y SPI. Maughan, et. al. Pila de Estándares [Pág. 7] RFC 2408 ISAKMP Noviembre 1998 1.4.1 Asociaciones de Seguridad y Registraciones Los atributos requeridos y recomendados para una SA IPsec (AH, ESP) están definidos en [SEC-ARCH]. Los atributos específicos para una SA IPsec incluyen, pero no están limitados a, mecanismos de autentificación, algoritmos criptográficos, modos de algoritmos, longitud de las claves, y el Vector de Inicialización (IV). Otros protocolos que proporcionen algoritmos y mecanismos independientes de seguridad DEBEN definir sus requerimientos para los atributos de las SAs. La separación de una definición específica de SA ISAKMP es importante para asegurar que ISAKMP pueda establecer SAs para todos los posibles protocolos de seguridad y aplicaciones. NOTA: Vea [IPDOI] para un debate de los atributos de las SA que deberían ser considerados para las definiciones de un protocolo de seguridad o aplicaciones. Para facilitar la rápida identificación de atributos específicos (por ejemplo, un algoritmo de encriptación específico) entre varias entidades se DEBEN designar identificadores de atributos y estos identificadores deben ser registrados por una autoridad central. La Autoridad de Asignación de Números en Internet (IANA) proporciona esta función para Internet. 1.4.2 Requisitos de ISAKMP El establecimiento de SA DEBE ser parte del protocolo de manejo de claves definidos para las redes basadas en IP. El concepto de SA es requerido para soportar protocolos de seguridad en ambientes diversos y dinámicos de red. La autentificación y el intercambio de claves deben estar vinculados para asegurar que la clave este establecida con la parte autentificada [DOW92], el establecimiento de una SA debe estar vinculado con la autentificación y el protocolo de intercambio de claves. ISAKMP proporciona el protocolo de intercambio para establecer una SA entre entidades negociantes después del establecimiento de una SA para estas entidades negociantes en representación de algún protocolo (por ejemplo ESP/AH). Primero, un intercambio inicial de protocolo permite un conjunto de atributos de seguridad acordados. Este conjunto básico proporciona protección para los intercambios subsiguientes de ISAKMP. También indica el método de autentificación y el intercambio de claves que serán realizados como parte del protocolo ISAKMP. Si un conjunto básico de atributos de seguridad ya esta en su sitio entre las entidades de negociación del servidor, el intercambio ISAKMP inicial puede ser omitido y el establecimiento de la SA puede ser realizado directamente. Después de que el conjunto básico de atributos de seguridad haya sido acordado, la autenticidad Maughan, et. al. Pila de Estándares [Pág. 8] RFC 2408 ISAKMP Noviembre 1998 de identidad inicial, y las claves requeridas generadas, la SA establecida puede ser usada para comunicaciones subsiguientes por la entidad que invocó a ISAKMP. El conjunto básico de atributos de SA que DEBE ser implementado para proporcionar interoperatibilidad entre ISAKMPs están definidos en el Apéndice A. 1.5 Autentificación Un paso muy importante en el establecimiento de comunicaciones de red seguras es la autentificación de la entidad en el otro extremo de la comunicación. Muchos mecanismos de autentificación están disponibles. Los mecanismos de autentificación pueden clasificarse dentro de dos categorías: Débiles y fuertes. Enviar claves de texto sin encriptar (texto en claro - cleartext) o otra información de autentificación sin protección en una red es débil, debido a la amenaza de lecturas con sniffer de red. El envío unidireccional de claves hasheadas (a las cuales se les hizo un resumen criptográfico) deficientemente elegidas con baja entropía son también débiles, debido a la amenaza de ataques por fuerza bruta en los mensajes sniffer. Mientras que los passwords pueden ser usados para el establecimiento de identidades, no son considerados en este contexto, debido a declaraciones resientes del Consejo de Arquitectura de Internet [IAB]. Las firmas digitales, tales como el Estándar de Firmas Digitales (DDS: Digital Signature Standard) y las firmas Rivest-Shamir-Adleman (RSA) son claves públicas basadas en fuertes mecanismos de autentificación. Al usar claves públicas para firmas digitales, cada entidad requiere una clave pública y una privada. Los certificados son una parte esencial de los mecanismos de autentificación en una firma digital. Los certificados vinculan la identidad de una entidad específica (ya sea un host, un usuario o una aplicación) a sus claves públicas y posiblemente a otra información de seguridad relacionada tales como privilegios, eliminaciones [clearances] y secciones [compartments]. La autentificación basada en firmas digitales requiere una tercera parte confiable o la creación de autoridades de certificación, la cuál firma y distribuye correctamente los certificados. Para información más detallada sobre firmas digitales, tales como DSS y RSA, y certificados ver [Schneier]. 1.5.1 Autoridades de Certificación Los certificados requieren una infraestructura para la generación, verificación, revocación, administración y distribución. La Autoridad de Registración de Políticas en Internet (IPRA) [RFC-1422] a sido establecida para dirigir esta infraestructura por la IETF. La IPRA certifica las Autoridades de Certificación de Políticas (PCA). Las PCAs controlan a las Autoridades de Certificación (CA) las cuales certifican usuarios y entidades dependientes. El trabajo relacionado con la certificación actual incluye a los Sistemas de Nombres de Maughan, et. al. Pila de Estándares [Pág. 9] RFC 2408 ISAKMP Noviembre 1998 Dominio (DNS) y a las Extensiones de Seguridad [DNSSEC] las cuales proporcionan la clave firmada a la entidad en el DNS. El Grupo de Trabajo para la Infraestructura de Clave Pública (PKIX) especifica un perfil para Internet para los certificados X.509. Existen también trabajos realizados en la industria para desarrollar Servicios de Directorios X.500 que podrían proporcionar certificados X.509 a los usuarios. La oficina de correo de USA esta desarrollando una jerarquía de Autoridades de Certificación (CA). El Grupo de Trabajo para la Infraestructura de Clave Pública NIST ha estado desarrollando investigaciones en esta área. La Iniciativa de Seguridad de Sistemas de Información Multinivel (MISSI) del Departamento de Defensa del gobierno de USA (DOD) ha comenzado a desarrollar una infraestructura de certificación para el gobierno de USA. Alternativamente si no existe ninguna infraestructura de clave pública, Los PGP certificados de Red de Confianza (Web of Trust certificates) pueden ser utilizados para proporcionar autentificación y privacidad para el usuario en una comunidad de usuarios que se conocen y confían mutuamente. 1.5.2. Nombramiento de la Entidad El nombre de la entidad es su identidad y está ligado a su clave pública en los certificados. Las CA DEBEN definir la semántica para el nombramiento de los certificados. Vea UNINETT PCA Policy Statements [Berge] como un ejemplo de como una CA define su política de nombramiento. Cuando se verifica un certificado, el nombre es verificado y ese nombre tendrá significado dentro del dominio de esa CA. Un ejemplo son las extensiones de seguridad de los DNS que hacen los servidores CAs del DNS para las zonas y los nodos a los cuales sirven. Los registros de recursos se proporcionan para las claves públicas y las firmas de esas claves. Los nombres asociados a esas claves son asociados con las direcciones IP y con los nombres de dominio los cuales tienen un significado para las entidades que tienen acceso al DNS para esa información. Una Red de Confianza es otro ejemplo. Cuando se implementan redes de confianza, los nombres están ligados a las claves públicas. En PGP usualmente el nombre de la entidad es usualmente la dirección de e-mail el cuál tiene significado para aquellos, y solamente para aquellos que entienden el correo electrónico. Otra red de confianza podría utilizar un esquema de nombramiento totalmente diferente. 1.5.3 Requerimientos de ISAKMP La autentificación fuerte DEBE ser proporcionada en los intercambios ISAKMP. Si no se puede autentificar a la entidad del otro extremo, la SA y el establecimiento de claves de sesión serán dudosos. Sin la autentificación no se puede confiar en la identificación de la entidad, lo que hace al control de acceso cuestionable. Mientras que la encriptación (por ejemplo ESP) y la integridad (por ejemplo AH) Maughan, et. al. Pila de Estándares [Pág. 10] RFC 2408 ISAKMP Noviembre 1998 protegerán comunicaciones subsiguientes de mirones (sniffer) pasivos, sin autentificación es posible que la SA y las claves hayan sido establecidas por otras personas, las cuales realizaron un ataque activo modificando el flujo de datos trasmitidos interfiriendo la comunicación y ahora se está robando toda su información personal. Un algoritmo de firma digital DEBE ser usado dentro del componente de autentificación de ISAKMP. Sin embargo, ISAKMP no dictamina un algoritmo para las firmas digitales o Autoridad de Certificación (CA) específico. ISAKMP permite a una entidad iniciar una comunicación indicando que CAs esta utilizando. Después de la selección de una CA, el protocolo proporciona la infraestructura para utilizar el intercambio de autentificación actual. El protocolo proporciona facilidades para la identificación de diferentes autoridades de certificación, tipos de certificados (por ejemplo X.509, PKCS #7, PGP, DNS SIG y registro de claves) y el intercambio de certificados determinados. ISAKMP utiliza firmas digitales, basadas en criptografía de clave pública, para la autentificación. Existen otros sistemas fuertes de autentificación disponible, que se podrían especificar como mecanismos opcionales de autentificación para ISAKMP. Algunos de estos sistemas de autentificación confían en una tercera parte llamada Centro de Distribución de Claves (KDC), para distribuir claves de sesiones secretas. Un ejemplo es Kerberos, donde la tercera parte confiable es el servidor de Kerberos, que guarda las claves secretas de todos sus clientes y servidores dentro de su dominio de red. Un cliente que tiene una clave secreta proporciona autentificación ante servidores. Las especificaciones de ISAKMP no especifican el protocolo para la comunicación con las Terceras Partes de Confianza (TTP) o los servicios de directorios de certificados. Estos protocolos están definidos por las TTP y los servicios de directorios y están fuera del alcance de estas especificaciones. El uso de estos servicios adicionales y protocolos serán descriptos en un documento específico de intercambio de claves. 1.6 Criptografía de Clave Pública La criptografía de clave pública es un modo más flexible, escalable y eficiente para que los usuarios obtengan secretos y claves compartidas para soportar un gran número de formas para ínter-operar con los usuarios de Internet. Muchos algoritmos de generación de claves, que tienen diferentes propiedades, están disponibles para los usuarios (ver [DOW92], [ANSI], y [Oakley]). Las propiedades de los Maughan, et. al. Pila de Estándares [Pág. 11] RFC 2408 ISAKMP Noviembre 1998 protocolos de intercambio de claves incluyen un método para el establecimiento de claves, autentificación, simetría, perfect forward secrecy y la protección posterior del tráfico. NOTA: Las claves criptográficas pueden proteger información por largos periodos de tiempo. Sin embargo esto se basa en la presunción de que las claves son usadas para la protección de comunicaciones y son destruidas después de haber sido usadas y no son almacenadas por ninguna razón. 1.6.1 Propiedades del Intercambio de Claves Establecimientos de Claves (Generación de Claves/Trasporte de claves): Los dos métodos más comunes de criptografía de clave pública para el establecimiento de claves son, trasporte de claves y generación de claves. Un ejemplo de trasporte de claves es el uso de algoritmos RSA para encriptar una clave de sesión generada aleatoriamente (para encriptar comunicaciones subsiguientes) con los receptores de las claves públicas. La clave aleatoriamente encriptada es luego enviada al receptor, que la desencripta utilizando su clave privada. En este punto ambos extremos de la comunicación, tienen la misma clave de sesión, sin embargo esta fue creada a partir de la entrada de información unidireccional de la comunicación. La ventaja del método de trasporte de claves es que tiene menos gasto computacional que el siguiente método. El algoritmo de Diffie-Hellman (D-H) ilustra la generación de claves utilizando criptografía de clave pública. El algoritmo D-H se inicia con dos usuarios que intercambian información pública. Cada usuario después combina matemáticamente la información pública del otro usuario con su propia información secreta para calcular un valor secreto compartido. Este valor secreto puede ser utilizado como una clave de sesión o como una clave de encriptación de clave para encriptar la clave de sesión generada aleatoriamente. Este método genera una clave de sesión basada en información pública y secreta, compartida por ambos usuarios. La ventaja del algoritmo de D-H es que la clave usada para encriptar mensajes se obtiene de la información compartida por ambos usuarios y la independencia de las claves entre un intercambio de claves y el otro proporciona perfect forward secrecy. Descripciones detalladas de estos algoritmos pueden ser encontradas en [Schneier]. Hay varias versiones de estos dos esquemas de generación de claves pero estas versiones no necesariamente deben interrelacionarse. Autentificación del intercambio de claves: Los intercambios de claves pueden ser autentificados durante el protocolo o después del protocolo. La autentificación del intercambio de claves durante el protocolo se lleva a cabo cuando cada parte proporciona prueba de que tiene la clave de sesión secreta antes de finalizar el protocolo. La prueba puede ser proporcionada encriptando datos conocidos en la Maughan, et. al. Pila de Estándares [Pág. 12] RFC 2408 ISAKMP Noviembre 1998 sesión de claves secretas durante el intercambio del protocolo. La autentificación después del protocolo debe ocurrir en comunicaciones subsiguientes. La autentificación durante el protocolo es la que se prefiere. Por lo tanto las comunicaciones subsiguientes no son iniciadas si la clave de sesión secreta no esta establecida con la parte deseada. Intercambio de claves simétrico: un intercambio de claves proporciona simetría si cualquier parte puede iniciar el intercambio y los mensajes intercambiados pueden cruzarse en la trayectoria sin afectar la clave que es generada. Esto es provechoso para que el cálculo de claves no requiera que cada parte sepa quien inició el intercambio. A pesar de que el intercambio de claves simétricos es provechoso, la simetría en el protocolo de administración de claves puede proporcionar vulnerabilidad a los ataques de reflexión (reflection attacks). Perfect Forward Secrecy: según lo descripto en [DOW92], un protocolo de intercambio de claves autentificado, proporciona perfect forward secrecy si la divulgación del material clave por largo tiempo no compromete la confidencialidad del intercambio de claves de las comunicaciones previas. Las características del perfect forward secrecy no se aplican al intercambio de claves cuando este está desprovisto de 1.6.2 Requisitos para ISAKMP Un intercambio de claves autentificado debe ser utilizado por ISAKMP. Los usuarios DEBERÍAN elegir los algoritmos de establecimiento de claves adicionales basándose en sus propios requerimientos. ISAKMP no especifica un intercambio de claves determinado. Sin embargo, [IKE] describe una propuesta para el uso de [Oakley] en conjunto con ISAKMP. Los requerimientos que deben ser evaluados al elegir un algoritmo de establecimiento de claves deben incluir el método de establecimiento (generación o trasporte), perfect forward secrecy, el costo computacional, depósito de claves, y robustez de las claves. De acuerdo con los requerimientos del usuario, ISAKMP permite a una entidad iniciar comunicaciones para que indique que intercambio de claves soporta. Después de la selección de un intercambio de claves el protocolo proporciona los mensajes requeridos para soportar el establecimiento de la verdadera clave. 1.7 Protección ISAKMP 1.7.1 Anti-Saturación (Denegación de Servicio) De los numerosos servicios de seguridad disponibles, la protección contra la denegación de servicio siempre va ha ser uno de los más Maughan, et. al. Pila de Estándares [Pág. 13] RFC 2408 ISAKMP Noviembre 1998 difíciles de tratar. Un "cookie" o token anti-saturación (ACT) está destinado a la protección de recursos computacionales de ataques sin malgastar recursos excesivos de CPU, para determinar sus autenticidades. Un intercambio previo con operaciones de claves públicas que consuman mucha CPU pueden frustrar ciertas tentativas de denegación de servicios (por ejemplo, con inundaciones de falsas direcciones IP de origen). La protección absoluta contra la denegación de servicio es imposible pero este token anti-saturación proporciona una técnica para hacerlo más fácil de manejar. El uso del token anti-saturación fue introducido por Karn y Simplón en [Karn]. Como se observará en los intercambios mostrados en la sección 4, los mecanismos de anti-saturación deberían ser usados en conjunto con mecanismos de recolección de información de estado no válida; un atacante silencioso puede inundar un servidor usando paquetes con direcciones IP falsas y se creará la causa producida. Tales técnicas de administración de memoria agresiva DEBERÍAN ser empleados por los protocolos que utilizan ISAKMP, que no realizan un minucioso examen inicial, solo en la fase de anti-saturación, como se describe en [Karn]. 1.7.2 Secuestro de la Conexión ISAKMP previene el secuestro de la conexión vinculando la autentificación, el intercambio de claves y el intercambio de SAs. Esta vinculación impide a un atacante completar la autentificación y que luego intervenga y tome la personalidad de una entidad durante los intercambios de claves y SA. 1.7.3 Ataques en la Trayectoria (Man-in-the-Middle Attacks) La intercepción de atacantes en la trayectoria (Man-in-the-Middle Attacks) incluyen: la intercepción, la inserción, la cancelación y la modificación de mensajes, mensajes reflejados por atrás del emisor reeditando mensajes viejos y redireccionando mensajes. Las características de ISAKMP evitan que estos tipos de ataques sean exitosos. La vinculación de intercambios ISAKMP previene la inserción de mensajes en el intercambio de los protocolos. La máquina de estado del protocolo ISAKMP se define como un eliminador de mensajes, que no permite que SA parciales sean creadas, la máquina de estado eliminará todos los estados y volverá a la inactividad. La máquina de estado también evita que la reflexión de un mensaje cause daños. Los requerimientos para una nueva cookie con contenido dinámico para cada nueva SA establecida previene de ataques que involucren el reenvío de mensajes viejos. El requerimiento de autentificación fuerte de ISAKMP previene que una SA sea establecida con cualquier otra parte que no sea la deseada. Los mensajes pueden ser redireccionados a un destino diferente o modificados pero esto será detectado y una SA no será Maughan, et. al. Pila de Estándares [Pág. 14] RFC 2408 ISAKMP Noviembre 1998 establecida. La especificación de ISAKMP define donde a ocurrido un procesamiento anormal y recomienda notificar a la parte apropiada de esta anormalidad. 1.8 Comunicaciones Multicast Se espera que las comunicaciones multicast requieran de los mismos servicios de seguridad que las comunicaciones unicast y pueden introducir la necesidad de servicios de seguridad adicionales. Los asuntos para la distribución de SPIs para el tráfico multicast son presentadas en [SEC-ARCH]. Los temas de multicast también son debatidos en [RFC-1949] y en [BC]. Una extensión futura para ISAKMP soportará la distribución de claves multicast. Para una introducción en estos temas relacionados con la seguridad multicast, consulte los Drafts de Internet, [RFC-2094] y [RFC-2093], que describiendo la investigación de Sparta's en esta área. 2. Conceptos y Terminologías 2.1 Terminología de ISAKMP Protocolo de Seguridad: Un Protocolo de Seguridad consiste en una entidad de un solo extremo en la pila de red, realizando un servicio de seguridad para las comunicaciones de red. Por ejemplo, ESP IPsec, AH IPsec, son dos diferentes protocolos de seguridad. TLS es otro ejemplo. Los protocolos de seguridad pueden proporcionar más de un servicio, por ejemplo proporcionar integrabilidad y confidencialidad en un solo módulo. Conjunto de Protección: Un conjunto de protección es una lista de servicios de seguridad que debe ser aplicada por varios protocolos de seguridad. Por ejemplo, un conjunto de protección puede consistir de encriptación DES en ESP IP, y una clave MD5 en AH IP. Todas las protecciones en un conjunto deben ser tratadas como una unidad simple. Esto es necesario porque los servicios de seguridad en diferentes protocolos de seguridad pueden tener sutiles interaccionés, y los efectos de un conjunto deben ser analizados y verificados como un todo. Asociación de seguridad (SA): Una Asociación de seguridad es un conjunto de parámetros específicos del protocolo de seguridad que definen completamente los servicios y mecanismos necesarios para proteger el tráfico en ese lugar del protocolo de seguridad. Estos parámetros pueden incluir identificadores de algoritmo, modos, claves criptográficas, etc. La SA hace referencia a su protocolo de seguridad asociado (por ejemplo "SA ISAKMP", "SA ESP", "SA TLS"). Maughan, et. al. Pila de Estándares [Pág. 15] RFC 2408 ISAKMP Noviembre 1998 SA ISAKMP: Una SA usada por los servidores ISAKMP para proteger su propio tráfico. Las Secciones 2.3 y 2.4 proporcionan más detalles acerca de las SAs ISAKMP. Índice de parámetros de seguridad (SPI): Un identificador para una Asociación de Seguridad, relativo a algún protocolo de seguridad. Cada protocolo de seguridad tiene su propio "espacio-SPI". Un par (protocolo de seguridad, SPI) pueden identificar unívocamente a una SA. La unívocariedad (exclusividad) de la SPI es dependiente de la implementación, pero puede estar basada en sistemas, en protocolos, u otras opciones. Dependiendo del DOI, información adicional (por ejemplo, las direcciones de los host) puede ser necesarias para identificar a una SA. El DOI también determinará cuales SPIs (es decir, los SPIs del iniciador o del respondedor) son enviados durante la comunicación. Dominio de Interpretación (DOI): Un Dominio de Interpretación (DOI) define los formatos de cargas, tipos de intercambio, y convenciones para nombrar información relevante a la seguridad tales como políticas de seguridad o algoritmos criptográficos y modos. Un identificador de Dominio de Interpretación (DOI) es usado para interpretar las cargas de las cargas ISAKMP. Un sistema DEBERÍA soportar múltiples Dominios de Interpretación simultáneamente. El concepto de DOI se basa en trabajos previos del Grupo de Trabajo de TSIG CIPSO, pero se extiende más allá de la interpretación de etiquetas de seguridad para incluir el nombramiento y la interpretación de los servicios de seguridad. Un DOI define: o Una "situación": el conjunto de información que será usado para determinar los servicios de seguridad requeridos. o El conjunto de políticas de seguridad que deben o podrían ser soportados. o La sintaxis para la especificación de los propósitos de los servicios de seguridad sugeridos. o Un esquema para nombrar información relativa a la seguridad, incluyendo algoritmos de encriptación, algoritmos de intercambio de claves, atributos de política de seguridad y autoridades de certificación. o Los formatos específicos de los contenidos de las diversas cargas. o Tipos de intercambio adicionales, si son requeridos. Maughan, et. al. Pila de Estándares [Pág. 16] RFC 2408 ISAKMP Noviembre 1998 Las reglas de Seguridad DOI IP IETF se presentan en [IPDOI]. Las especificaciones de las reglas para DOI personalizados serán presentadas en documentos separados. Situación: Una situación contiene toda la información relevante a la seguridad que un sistema considera necesaria para decidir los servicios de seguridad requeridos para proteger las sesiones que están siendo negociadas. La situación puede incluir direcciones, clasificaciones de seguridad, modos de operación, (normal vs. emergencia), etc. Proposición: una proposición es una lista, en orden decreciente de preferencia, del conjunto de protecciones que un sistema considera aceptable para proteger el tráfico bajo una situación dada. Carga: ISAKMP define varios tipos de cargas, que son usadas para trasmitir información según los datos de la SA, o los datos del intercambio de claves, dentro de las formas definidas en el DOI. Una carga consiste en una cabecera de carga genérica y en octetos encadenados que están ocultos para ISAKMP. ISAKMP usa funcionalidades específicas del DOI para sintetizar e interpretar esas cargas. Múltiples cargas pueden ser enviadas en un único mensaje de ISAKMP. Ver la Sección 3 para más detalles de tipos de carga, y [IPDOI] para los formatos de seguridad de cargas DOI IP IETF. Tipos de Intercambios: Un tipo de intercambio es una especificación de un número de mensajes en un intercambio ISAKMP, y los tipos de carga que están contenidos en cada uno de estos mensajes. Cada tipo de intercambio está diseñado para proporcionar, un conjunto especifico de servicios de seguridad, tales como el anonimato de los participantes, perfect forward secrecy del material clave, autentificación para los participantes, etc. En la Sección 4.1 se define el conjunto por defecto de tipos de intercambio ISAKMP. Otros tipos de intercambio se pueden agregar para soportar intercambios adicionales de claves, si es requerido. 2.2 Ubicación de ISAKMP La Figura 1 es una vista de la ubicación de ISAKMP dentro de un contexto de un sistema en una arquitectura de red. Una parte importante de la negociación de los servicios de red es considerar a la "PILA" entera de las SAs como una unidad. Esto se lo denomina "conjunto de protección". Maughan, et. al. Pila de Estándares [Pág. 17] RFC 2408 ISAKMP Noviembre 1998 +------------+ +--------+ +-------------------------+ ! Definición ! ! ! ! Procesos de ! ! del DOI ! <------> ! ISAKMP ! ! aplicación ! +------------+ --> ! ! !-------------------------! +---------------------+ ! +--------+ ! Protocolo de Aplicación ! ! Definición del ! ! ^ ^ +-------------------------+ !intercambio de claves! <-- ! ! ^ +---------------------+ ! ! ! ! ! ! !-------------------! ! ! v ! ! +-------+ v v ! API ! +---------------------------------------------+ +-------+ ! Capa Socket ! ! !---------------------------------------------! v ! Protocolo de Trasporte (TCP / UDP) ! +------------+ !---------------------------------------------! ! Protocolo ! <--> ! IP ! !de seguridad! !---------------------------------------------! +------------+ ! Protocolo de la Capa de Enlace ! +---------------------------------------------+ Figura 1: Ubicación de ISAKMP 2.3 Fases de la Negociación ISAKMP ofrece dos "fases" para la negociación. En la primera fase, dos entidades (por ejemplo, servidores ISAKMP) concuerdan en como proteger futuras negociaciones del tráfico entre ellas mismas, estableciendo una SA ISAKMP. Esta SA ISAKMP es luego usada para proteger las negociaciones requeridas por las SA de los Protocolos. Dos entidades (por ejemplo, servidores de ISAKMP) pueden negociar (si están activos) múltiples SA ISAKMP. La segunda fase de la negociación es usada para establecer la SA para otros protocolos de seguridad. Esta segunda fase puede ser usada para establecer múltiples SA. Las SA establecidas por ISAKMP durante esta fase pueden ser usadas por un protocolo de seguridad para proteger los intercambios de datos/mensajes. Mientras que este método de dos fases tiene un costo elevado para la inicialización en la mayoría de los escenarios simples, hay varias razones por la que este método es beneficioso en la mayoría de los casos. Primero, las entidades (por ejemplo servidores ISAKMP) pueden amortizar el costo de la primera fase a través de varias negociaciones en la segunda fase. Esto permite que múltiples SAs Maughan, et. al. Pila de Estándares [Pág. 18] RFC 2408 ISAKMP Noviembre 1998 estén relacionadas entre usuarios por un cierto lapso de tiempo sin tener que iniciar cada una de las comunicaciones. Segundo, los servicios de seguridad negociados durante la primer fase proporcionan propiedades de seguridad para la segunda fase. Por ejemplo, después de la negociación de la primera fase, la encriptación proporcionada por la SA ISAKMP puede proporcionar protección de identidad, potencialmente permitiendo el uso de intercambios más simples, en la segunda fase. Por otra parte, si un canal establecido durante la primera fase no es adecuado para proteger las identidades, la segunda fase luego deberá negociar los mecanismos de seguridad adecuados. Tercero, tener una SA ISAKMP reduce considerablemente el costo de actividad de administración externo a ISAKMP brindando una "trayectoria confiable" para una SA ISAKMP, las entidades (por ejemplo servidores de ISAKMP) tendrían que pasar por una reautorización completa de cada error de notificación o la cancelación de una SA. La negociación llevada a cabo en cada fase es realizada usando intercambios ISAKMP definidos (ver Sección 4) o intercambios definíos en un intercambio de claves dentro de un DOI. Note que los servicios de seguridad se pueden aplicar de manera diferente en cada una de las fases de la negociación. Por ejemplo, diferentes partes son autentificadas durante cada una de las fases de la negociación. Durante la primera fase, las partes que son autentificadas pueden ser servidores ISAKMP o host, mientras que en la segunda fase usuarios o programas de nivel de aplicación son autentificados. 2.4 Identificar SA A pesar de que existen canales seguros de bootstrapping entre sistemas, ISAKMP no puede asumir la existencia de servicios de seguridad, y debe proporcionar algunas protecciones para sí mismo. Por lo tanto, ISAKMP considera una SA ISAKMP diferente a las de otros tipos y administra las SA ISAKMP para sí mismo, con su propio espacio de nombres. ISAKMP usa dos campos de cookies en la cabecera de ISAKMP para identificar SA ISAKMP. El Identificador (ID) de mensaje en la Cabecera de ISAKMP y el campo SPI en la carga de la Propuesta son usados durante el establecimiento de la SA para identificar la SA de otros protocolos de seguridad. La interpretación de estos 4 campos es dependiente de la operación que se lleve a cabo. Maughan, et. al. Pila de Estándares [Pág. 19] RFC 2408 ISAKMP Noviembre 1998 La tabla siguiente muestra la presencia o ausencia de diversos campos durante el establecimiento de la SA. Los siguientes campos son necesarios para las diversas operaciones asociadas con el establecimiento de la SA: cookies en la cabecera de ISAKMP, el campo ID (identificador) de mensaje en la cabecera de ISAKMP, y el campo SPI en la carga de la Propuesta. Una 'X' en la columna significa que el valor debe estar presente. Una 'NA' en la columna significa que el valor en la columna no es aplicable en esa operación. Cookie del Cookie del ID del # Operación Iniciador Respondedor Mensaje SPI (1) Inicio de la negociación SA X 0 0 0 ISAKMP (2) El respondedor de la X X 0 0 negociación SA ISAKMP (3) Iniciador, negociación de X X X X la otra SA (4) El respondedor, negociación X X X X de otra SA (5) Otros (KE, ID, etc.) X X X/0 NA (6) Protocolo de Seguridad NA NA NA X (AH, ESP) En la primera línea (1) de la tabla, el iniciador incluye el campo del Cookie del Iniciador en la cabecera de ISAKMP usando los procedimientos descriptos en las Secciones 2.5.3 y 3.1. En la segunda línea (2) de la tabla, el respondedor incluye los campos de las cookies del iniciador y del respondedor en la cabecera de ISAKMP usando los procedimientos descriptos en las Secciones 2.5.3 y 3.1. Mensajes adicionales pueden ser intercambiados entre usuarios ISAKMP, dependiendo del primer tipo de intercambio ISAKMP utilizado durante la primera fase de la negociación. Una vez que la primera fase del intercambio a finalizado, las cookies del iniciador y del respondedor son incluidos en la cabecera de ISAKMP para todas las comunicaciones subsiguientes entre los usuarios de ISAKMP. Durante la fase 1 de la negociación, la cookie del iniciador y del respondedor determinan la SA ISAKMP. Por lo tanto el campo SPI en la carga de la Propuesta es redundante y PUEDE cero (0) o PUEDE contener la identidad del cookie del transmisor. En la tercera línea (3) de la tabla, el iniciador asocia el ID (identificador) del Mensaje con los Protocolos contenidos en la Propuesta SA. Este ID (identificador) de Mensaje y los SPI del iniciador asociados con cada protocolo en la Propuesta son enviados al respondedor. Los SPI(s) serán utilizados por los protocolos de seguridad una vez que la fase 2 de la negociación este terminada. Maughan, et. al. Pila de Estándares [Pág. 20] RFC 2408 ISAKMP Noviembre 1998 En la cuarta línea (4) de la tabla, el que responde incluye el mismo Identificador de Mensaje y los mismos SPI(s) que están asociados con cada protocolo en la Propuesta aceptada. Esta información se devuelve al iniciador. En la quinta línea (5) de la tabla, el iniciador y el que responde usan el campo de ID (identificador) de Mensaje en la cabecera de ISAKMP para mantener el camino de la negociación del protocolo en proceso. Esto es solo aplicable para el intercambio de la fase 2 y el valor DEBE ser cero para el intercambio en la fase 1 por que las cookies combinadas identifican la SA ISAKMP. El campo SPI en la carga de la Propuesta no es aplicable por que la carga de la Propuesta es solamente usada durante los intercambios de negociación de mensajes de SA (pasos 3 y 4). En la secta línea (6) de la tabla, la fase 2 de la negociación es terminada. Los protocolos de seguridad usan los SPI(s) para determinar que mecanismos y servicios de seguridad aplicar a la comunicación entre ellos. El valor del SPI mostrado en la secta línea no es el campo SPI de la carga de la Propuesta sino que es el campo del SPI contenido dentro de la cabecera del protocolo de seguridad. Durante el establecimiento de la SA, una SPI debe ser generada. ISAKMP esta diseñado para tratar con SPIs de diferentes tamaños, esto se logra usando campos con tamaños de SPIs dentro de la carga de la Propuesta durante el establecimiento de la SA. El manejo de los SPIs será detallado por la especificación de DOI (por ejemplo [IPDOI]). Cuando una SA es inicialmente establecida, uno de los extremos asume el rol de iniciador y el otro el rol de respondedor. Una vez que la SA esta establecida, ambos el iniciador original y el respondedor original pueden iniciar la fase 2 de la negociación como entidades pares (peer entity). Por ende, las SA ISAKMP son bidireccionales por naturaleza. Además, ISAKMP permite al iniciador y al respondedor tener el mismo control durante el proceso de negociación. Mientras que ISAKMP es configurada para permitir la negociación de una SA que incluye múltiples propuestas, el iniciador puede mantener cierto control haciendo solamente una propuesta de acuerdo con la política de seguridad local del iniciador. Una vez que el iniciador envía una propuesta que contiene más de una propuesta (que son enviadas en orden decreciente de preferencia), el iniciador le pasa el control al respondedor. Una vez que el respondedor esta en control del establecimiento de la SA puede hacer que sus políticas tomen precedencia sobre las del iniciador dentro de un contexto de opciones Maughan, et. al. Pila de Estándares [Pág. 21] RFC 2408 ISAKMP Noviembre 1998 múltiples ofrecidas por el iniciador. Esto se logra seleccionando la mejor propuesta adecuada para la política de seguridad local del respondedor y devolviendo esta selección al iniciador. 2.5 Temas Diversos 2.5.1 Protocolo de trasporte ISAKMP puede ser implementado sobre cualquier protocolo de trasporte o sobre el mismo IP. Las implementaciones DEBEN incluir la capacidad de enviar y recibir tráfico ISAKMP utilizando el Protocolo de Datagrama de Usuario (UDP) sobre el puerto 500. El puerto UDP 500 ha sido asignado para el tráfico de ISAKMP por la Autoridad de Asignación de Números en Internet (IANA). Implementaciones adicionales PUEDEN soportar otros protocolos de trasporte o sobre el mismo protocolo IP. 2.5.2 Campos RESERVADOS La existencia de campos RESERVADOS dentro de la carga ISAKMP son usados estrictamente para preservar el alineamiento de los bytes. Todos los campos RESERVADOS en el protocolo ISAKMP DEBEN contener el valor cero (0) cuando un paquete es enviado. El receptor DEBERÍA corroborar que los campos RESERVADOS contengan el valor cero (0) y descartar el paquete si otros valores son encontrados 2.5.3 Creación de Token ("Cookies") Anti-Saturación Los detalles de la generación de cookies dependen de la implementación, pero DEBEN satisfacer estos requerimientos básicos (originariamente declarados por Phil Karn en [Karn]): 1. La cookie debe depender de las partes específicas. Esto evita que un atacante obtenga una cookie usando una dirección IP real y un puerto UDP, y luego use esto para saturar a la victima con peticiones de Diffie-Hellman a partir de direcciones IP o puertos elegidos aleatoriamente. 2. No debe ser posible que cualquier persona con excepción de la entidad emita la generación de cookies que serán aceptadas por esa entidad. Esto implica que la entidad emisora debe utilizar información local secreta en la generación y en las subsiguientes verificaciones de cookies. No debe ser posible deducir esta información secreta de ninguna cookie en particular. Maughan, et. al. Pila de Estándares [Pág. 22] RFC 2408 ISAKMP Noviembre 1998 3. La función de generación de cookies debe ser rápida para impedir ataques que intentan sabotear los recursos de la CPU. El método sugerido por Karn's para la creación de cookies es realizar un hash (por ejemplo MD5) sobre la dirección de origen y destino IP, la dirección de los puertos de origen y de destino UDP y un valor secreto aleatorio generado localmente. ISAKMP requiere que la cookie sea única para cada SA establecida con el propósito de ayudar a prevenir ataques de reenvío, por lo tanto, la fecha y el tiempo DEBEN ser agregados a la información condensada (hashed). Las cookies generadas son colocadas en los campos de las cookies del Iniciador y del Respondedor de la Cabecera ISAKMP (como se describe en la Sección 3.1). Estos campos tienen una longitud de 8 octetos, por ende se requiere que la cookie generada tenga 8 octetos. Los mensajes de Notificación y Cancelación (ver las Secciones 3.14, 3.15 y 4.8) unidireccionalmente trasmitidos y que están bajo la protección de una SA ISAKMP existente, no requerirán la generación de una nueva cookie. Una excepción a esto es la transmisión de un Mensaje de Notificación durante el intercambio de la fase 1, antes de terminar el establecimiento de una SA. Las Secciones 3.14 y 4.8 proporcionan detalles adicionales. 3 Cargas de ISAKMP Las cargas de ISAKMP proporcionan bloques modulares para la construcción de mensajes ISAKMP. La presencia y el ordenamiento de las cargas ISAKMP se define y depende del Campo Tipo de Intercambio ubicado en la Cabecera de ISAKMP (ver figura 2). Los tipos de carga de ISAKMP son analizados desde la Sección 3.4 hasta la Sección 3.15. Las descripciones de las cargas de ISAKMP, de los mensajes e intercambios se muestran usando el ordenamiento de octetos de red. 3.1 Formato de la Cabecera de ISAKMP El mensaje de ISAKMP tiene un formato de cabecera fijo, como muestra la figura 2, seguido por un número de cargas variables. Una cabecera fija simplifica el procesamiento, proporcionando el beneficio del análisis de procesamiento del software del Protocolo que es menos complejo y mas fácil de implementar. La cabecera fija contiene la información requerida por el protocolo para mantener el estado, procesar las cargas y posiblemente prevenir la denegación de servicio o ataques de reenvío. Los campos de la Cabecera ISAKMP se definen de la siguiente forma: Maughan, et. al. Pila de Estándares [Pág. 23] RFC 2408 ISAKMP Noviembre 1998 o Cookie del Iniciador (8 octetos): Cookie de la entidad que responde al requerimiento del establecimiento de una SA, o cancelación de la SA. o Cookie del Respondedor (8 octetos): Cookie de la entidad que responde al requerimiento del establecimiento de una SA, o cancelación de una SA. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cookie del ! ! Iniciador ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cookie del ! ! Respondedor ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! MjVer ! MnVer ! Tipo de Inter.! Banderas ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Identificador de Mensaje ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Longitud ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MjVer = Versión mayor; MnVer = Versión menor Figura 2: Formato de la Cabecera ISAKMP o Carga siguiente (1 octeto): indica el tipo de carga en el primer mensaje el formato de cada carga es definido desde la sección 3.4 hasta la sección 3.16. El procesamiento para las cargas se define en la sección 5. Maughan, et. al. Pila de Estándares [Pág. 24] RFC 2408 ISAKMP Noviembre 1998 Tipos de carga siguiente Valor Ninguno 0 Asociación de Seguridad (SA) 1 Propuesta (P) 2 Transformación (T) 3 Intercambio de claves (KE) 4 Identificación (ID) 5 Certificado (CERT) 6 Solicitud de certificado (CR) 7 Hash (HASH) 8 Firma (SIG) 9 Nonce (NONCE) 10 Notificación (N) 11 Cancelación (D) 12 Identificación del vendedor (VID) 13 RESERVADO 14-127 Uso privado 128-255 o Versión Mayor (4 bits): indica la versión mayor del protocolo ISAKMP en uso. Las implementaciones basadas en esta versión de Draft-Internet de ISAKMP DEBEN fijar la versión mayor en uno. Las implementación basadas en versiones previas de Draft-Internet de ISAKMP deben fijar la versión mayor en 0. Las implementaciones nunca DEBERÍAN aceptar paquetes con un número de versión mayor que estos. o Versión Menor (4 bits): indica la versión menor del protocolo ISAKMP en uso. Las implementaciones basadas en los Draft-Internet de ISAKMP DEBEN fijar la versión menor en cero. Las implementaciones basadas en versiones previas de los Draft- Internet de ISAKMP deben fijar la versión menor en 1. Las implementaciones nunca DEBERÍAN aceptar paquetes con un número de versión superior a estos, dado que los números de la versión mayor son idénticos. o Tipo de intercambio (1 octeto): Indica el tipo de intercambio que esta siendo usado. Esto indica los ordenamientos de los mensajes y la carga en los intercambios de ISAKMP. Maughan, et. al. Pila de Estándares [Pág. 25] RFC 2408 ISAKMP Noviembre 1998 Tipos de Intercambios Valor Ninguno 0 Base 1 Protección de Identidad 2 Solamente Autentificación 3 Agresivo 4 Informativo 5 Uso futuro de ISAKMP 6-31 Uso especifico del DOI 32-239 Uso privado 240-255 o Banderas (Flags) (1 octeto): Indica las opciones específicas que se fijan para los intercambios ISAKMP. Las banderas enumeradas debajo son específicas del campo de Banderas comenzando con el bit menos significativo, es decir el bit de Encriptación es el que se encuentra en la posición cero en el campo de Banderas, el bit de Commit está en la posición 1 en el campo de Banderas, y el bit de Solo Autentificación en la posición 2 del campo de Banderas. Los bits restantes del campo de Banderas se BEBEN fijar en cero antes de la transmisión. -- Bit de Encriptación (1 bit): si está en 1, todas las cargas que siguen a la cabecera son encriptadas usando algoritmos de encriptación, identificados por la SA ISAKMP. El identificador de la SA ISAKMP es la combinación de la cookie del iniciador y del respondedor. Se RECOMIENDA que la encriptación de las comunicaciones se realicen lo antes posible entre los usuarios. Para todos los intercambios ISAKMP descriptos en la Sección 4.1, la encriptación DEBERÍA comenzar después de que ambas partes hallan intercambiado las cargas de Intercambio de Claves. Si el Bit de encriptación no está en cero (0) las cargas no son encriptadas. -- Bit de Commit (1 bit): Este bit es usado para señalar la sincronización del intercambio de claves. Es usado para asegurar que el material encriptado no se reciba antes del término del establecimiento de la SA. EL bit de Commit puede ser fijado (en cualquier momento) por cualquiera de las partes que participan en el establecimiento de la SA, y puede ser usado durante las dos fases del establecimiento de la SA ISAKMP. Sin embargo, el valor DEBE ser puesto en cero (resetiado) después de la fase 1 de la negociación. Si está en (1), la entidad que no lo haya fijado DEBE esperar un Intercambio Informativo conteniendo una carga de Notificación (con el Mensaje de Notificación CONECTADO) de la entidad que fijó el Bit de Commit. En este caso, el campo Identificador de Mensaje del Intercambio Informativo DEBE contener el Identificador de Mensaje de la ISAKMP original de la fase 2 de Maughan, et. al. Pila de Estándares [Pág. 26] RFC 2408 ISAKMP Noviembre 1998 negociación de la SA. Esto se hace para asegurar que el Intercambio Informativo con el Mensaje de Notificación CONECTADO pueda ser asociado con la correcta fase dos de la SA. La recepción y procesamiento del Intercambio Informativo indica que el establecimiento de la SA fue exitoso y que cualquier entidad puede ahora proceder con la comunicación del tráfico encriptado. En sincronizaciones adicionales del intercambio de claves, el Bit de Commit puede ser usado para proteger contra la pérdida de trasmisiones en redes no confiables y para la defensa de múltiples retrasmisiones. NOTA: Es siempre posible que el mensaje final de un intercambio se pueda perder. En este caso, la entidad que se prepara para recibir el mensaje final de un intercambio recibiría el mensaje de la negociación de la fase 2 de la SA seguido de un intercambio de la fase 1 o el tráfico encriptado seguido de un intercambio de la fase 2. El manejo de esta situación no está estandarizado, pero proponemos las siguientes posibilidades. Si la entidad que espera el Intercambio Informativo puede verificar el mensaje recibido (es decir, el mensaje de negociación de la fase 2 de la SA o el tráfico encriptado), entonces PUEDE considerarse que la SA fue establecida y continuar con el procesamiento. Otra opción es retrasmitir el último mensaje ISAKMP para forzar a la otra entidad a retrasmitir el mensaje final. Esto sugiere que las implementaciones pueden considerar la retención del último mensaje (localmente) hasta que estén seguras de que la SA está establecida. -- Bit de Solo Autentificación (1 bit): este bit esta diseñado para ser usado con el Intercambio Informativo de una carga de Notificación y permitirá la transmisión de información con comprobación de integridad, pero no de encriptación (por ejemplo en modo de emergencia). La sección 4.8 indica que un Intercambio Informativo de la fase 2 DEBE ser enviado bajo la protección de una SA ISAKMP. Esto es solo una excepción a esa política. Si el bit de Solo Autentificación está en (1), solamente los servicios de autentificación de seguridad serán aplicados a toda la carga de Notificación de Intercambio Informativo y la carga no será encriptada. o Identificador (ID) de Mensaje (4 octetos): El Identificador de Mensaje solamente se usa para identificar el protocolo durante las negociaciones de la fase 2. Este valor es generado aleatoriamente por el iniciador de la fase 2. En el caso de establecimientos simultáneos de SA (es decir colisiones), el valor de este campo será probablemente diferente porque son generados independientemente y, así, dos SAs seguirán con el Maughan, et. al. Pila de Estándares [Pág. 27] RFC 2408 ISAKMP Noviembre 1998 establecimiento. Sin embargo es improbable de que existan establecimientos simultáneos. Durante las negociaciones de la fase 1, el valor DEBE ser cero. o Longitud (4 octetos): Longitud total del mensaje (cabecera más cargas) en octetos. La encriptación puede expandir el tamaño de un mensaje ISAKMP. 3.2 Cabecera de Carga Genérica Cada carga ISAKMP definidas desde la Sección 3.4 hasta la Sección 3.16 comienzan con una cabecera genérica, como se muestra en la Figura 3, la cual proporciona una capacidad de encadenamiento de carga y claramente define los límites de una carga. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 3: Formato de la Cabecera de Carga Genérica Los campos de la cabecera de la carga genérica son definidos de la siguiente forma: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. Este campo proporciona la capacidad de "encadenamiento". o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la carga (2 octetos): Longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. 3.3 Atributos de los Datos Hay varios casos dentro de ISAKMP donde es necesario representar los Atributos de los Datos. Un ejemplo de esto es los Atributos de la SA contenidas en la carga de Transformación (descriptos en la Sección 3.6). Estos Atributos de los Datos no son carga ISAKMP, pero están contenidos dentro de las cargas de ISAKMP. El formato de los Atributos de los Datos proporciona la flexibilidad para la representación de diferentes tipos de información. Pueden existir múltiples Atributos de los Datos dentro de una carga. La longitud de los atributos de los datos será de 4 octetos o estará definida por el campo Longitud de los Atributos. Esto es realizado usando el bit de Maughan, et. al. Pila de Estándares [Pág. 28] RFC 2408 ISAKMP Noviembre 1998 Formato de los Atributo descriptos debajo. La información específica acerca de los atributos para cada dominio será descripta en un documento DOI, por ejemplo, DOI IPsec [IPDOI]. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !A! Tipo de Atributo ! AF=0 Longitud del Atributo ! !F! ! AF=1 Valor del Atributo ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 4: Formato de los Atributo de los Datos Los campos de los Atributos de los Datos se definen de la siguiente forma: o Tipo de Atributo (2 octetos): identificador único para cada tipo de Atributo. Estos atributos se definen como parte de la información especifica del DOI. El bits más significativo, o Formato de Atributo (AF), indica si los atributos de los datos siguen el formato de Tipo/Longitud/valor (TLV) o uno más corto que sería; Tipo/valor (TV). Si el AF es cero (0), entonces los atributos de los datos tienen el formato Tipo/Longitud/valor (TLV). Si el bit AF es uno (1), entonces los Atributos de los Datos tienen el formato Tipo/Valor. o Longitud del Atributo (2 octetos): La longitud en octetos del Valor del Atributo. Cuando el bit AF está en uno (1), el Valor del Atributo es solamente de 2 octetos y el campo Longitud del Atributo no está presente. o Valor del Atributo (longitud variable): Valor del Atributo asociado con el Tipo de Atributo especifico del DOI. Si el bit AF esta en cero (0), este campo tiene una longitud variable determinada por el campo de Longitud del Atributo. Si el bit AF está en uno (1), el Valor del Atributo tiene una longitud de 2 octetos. 3.4 Carga SA La carga SA es usada para negociar los atributos de seguridad y para indicar el Dominio de Interpretación (DOI) y la situación bajo la cual esta tomando lugar. La Figura 5 muestra el formato de la carga SA. Maughan, et. al. Pila de Estándares [Pág. 29] RFC 2408 ISAKMP Noviembre 1998 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Dominio de Interpretación (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situación ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 5: Formato de la carga SA o Carga Siguiente (1 octeto): identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje este campo contendrá el valor cero (0). Este campo NO DEBE contener los valores de las cargas de la Propuesta o Transformación ya que estas son consideradas parte de la negociación de la SA. Por ejemplo, este campo contendría el valor "10" (carga Nonce), en el primer mensaje de un Intercambio Base (ver Sección 4.4) y el valor "0" en el primer mensaje en un Intercambio de Protección de Identidad (ver Sección 4.5). o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud en octetos de toda la carga SA, incluyendo la carga SA, todas las cargas de la Propuesta y todas las cargas de Trasformación asociadas con la SA propuesta. o Dominio de Interpretación (4 octetos): Identifica el DOI (como se describe en la Sección 2.1) bajo el cual la negociación se esta llevando a cabo. El DOI es un número entero sin signo de 32 bits. Un valor de DOI de cero durante el intercambio de la Fase 1 específica una SA ISAKMP genérica la cual puede ser usada por cualquier protocolo durante el intercambio de la Fase 2. Los Atributos SA necesarios están definidos en A.4. Un valor de DOI de 1 es asignado al DOI IPsec [IPDOI]. Todos los otros valores de DOI están reservados por la IANA para usos futuros. La IANA normalmente no asignará un valor a un DOI sin referirse a alguna especificación futura, tal como un futuro RFC. Otros DOI pueden ser definidos usando la descripción del Apéndice B. Este campo DEBE estar presente en la carga SA. o Situación (longitud variable): Un campo específico del DOI que identifica la situación bajo la cual la negociación se esta llevando a cabo. La Situación es usada para tomar las decisiones Maughan, et. al. Pila de Estándares [Pág. 30] RFC 2408 ISAKMP Noviembre 1998 de política concerniente a los atributos de seguridad que están siendo negociadas. Las especificaciones para la Situación del DOI de Seguridad IP de la IETF se define en [IPDOI]. Este campo DEBE estar presente en la carga SA. 3.5 Carga de la Propuesta La Carga de la Propuesta contiene información usada durante la negociación de la SA. La propuesta consiste en mecanismos de seguridad, o trasformaciones, que serán usados para asegurar el canal de comunicaciones. La Figura 6 muestra el formato de la Carga de la Propuesta. Una descripción de su uso puede encontrarse en la Sección 4.2. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Nº de Propuesta! ID Protocolo !Tamaño del SPI !Nº de Transfor.! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI (variable) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 6: Formato de la Carga de la Propuesta Los campos de la Carga de la Propuesta se definen de la siguiente forma: o Carga siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Este campo DEBE contener solamente el valor 2 o cero. Si hay Cargas de la Propuesta adicionales en el mensaje, este campo tendrá el valor 2. Si la carga de la Propuesta actual es la última dentro de la propuesta de la SA, este campo tendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud en octetos de toda la carga de la Propuesta, incluyendo la cabecera de carga genérica, la carga de la Propuesta, y todas las cargas de Transformación asociadas con esta propuesta. En el caso de que existan múltiples propuestas con el mismo número de propuesta (ver la Sección 4.2), el campo Longitud de la Carga solamente se aplica a la carga de la Propuesta actual y no a todas. Maughan, et. al. Pila de Estándares [Pág. 31] RFC 2408 ISAKMP Noviembre 1998 o Número de Propuesta (1 octeto): Identificador del número de Propuesta para la carga actual. Una descripción del uso de este campo se encuentra en la Sección 4.2. o Identificador de Protocolo (1 octeto): Especifica el Identificador de Protocolo para la negociación actual. Ejemplos pueden incluir ESP IPSEC, AH IPSEC, OSPF, TLS, etc. o Tamaño del SPI (1 octeto): La longitud en octetos del SPI como es definido por el Identificador de Protocolo. En el caso de ISAKMP, el par de cookies del Iniciador y del Respondedor de la Cabecera de ISAKMP es el SPI de ISAKMP, por lo tanto, el Tamaño del SPI es irrelevante y PUEDE variar desde 0 a 16. Si el Tamaño del SPI no es cero, el contenido del campo de SPI DEBE ser ignorado. Si el Tamaño del SPI no es múltiplo de 4 octetos tendrá algún tipo de incidencia en el campo del SPI y de la alineación de todas las cargas en el mensaje. El DOI establecerá el tamaño del SPI para otros protocolos. o Número de Trasformaciones (1 octeto): Especifica el número de trasformaciones de la Propuesta. Cada uno de estos está contenido en una carga de Transformación. o SPI (variable): El SPI de la entidad emisora. En el caso de que el Tamaño del SPI no sea múltiplo de 4 octetos, no habrá relleno aplicable a la carga, sin embargo, este puede ser aplicado al final del mensaje. El tipo de carga para la Carga de la Propuesta es dos (2) 3.6 Carga de Transformación La Carga de Transformación contiene información usada durante la negociación de la SA. La Carga de Transformación consiste en un mecanismo de seguridad específico, o trasformaciones, con el objetivo de asegurar el canal de comunicación. La carga de Transformación también contiene los atributos SA asociados con la transformación específica. Estos atributos SA están especificados en el DOI. La Figura 7 muestra el formato de la Carga de Transformación. Una descripción de su uso puede ser encontrado en la Sección 4.2. Maughan, et. al. Pila de Estándares [Pág. 32] RFC 2408 ISAKMP Noviembre 1998 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Nº de Transfor.! ID-Transfor. ! RESERVADO2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Atributos de la SA ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 7: Formato de la Carga de Transformación Los campos de la Carga de Transformación se definen de la siguiente forma: o Carga siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Este campo solamente DEBE contener el valor 3 o cero. Si hay cargas de Transformación adicionales en la propuesta, este campo contendrá el valor 3. Si la carga de Transformación actual es la última dentro de la propuesta, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la carga (2 octetos): La longitud en octetos de la presente carga, incluyendo la cabecera de carga genérica, valores de Transformación, y todos los Atributos SA. o Número de transformación (1 octeto): Identifica el número de Transformación de la presente carga. Si hay más de una transformación propuesta para un protocolo específico, dentro de la carga de transformación, cada carga de Transformación tiene un único Número de Transformación. Una descripción del uso de este campo se encuentra en la Sección 4.2. o Identificador de Transformación (1 octeto): Especifica el identificador de Transformación para el protocolo dentro de la propuesta actual. Estas trasformaciones están definidas por el DOI y dependen del protocolo que se está negociando. o RESERVADO2 (1 octeto): No utilizado, debe contener ceros. o Atributos SA (longitud variable): Este campo contiene los atributos de la SA como están definidos para la trasformación dada en el campo Identificador de Transformación. Los Atributos Maughan, et. al. Pila de Estándares [Pág. 33] RFC 2408 ISAKMP Noviembre 1998 SA se BEBERÍAN representar usando el formato de los Atributos de los Datos descriptos en la Sección 3.3. Si los atributos de la SA no están alineados en límites de 4 byte, las cargas subsiguientes no estarán alineadas y algún tipo de relleno será agregado al final del mensaje para crear un mensaje alineado a 4 octetos. El tipo de carga para la Carga de Transformación es tres (3) 3.7 Carga de Intercambio de Claves La Carga de Intercambio de Claves soporta una variedad de técnicas de intercambio de claves. Ejemplos de intercambio de claves son Oakley [Oakley], Diffie-Hellman, el intercambio de claves mejorado de Diffie-Hellman descripto en x9.42 [ANSI], y el intercambio de claves basado en RSA usado por PGP. La Figura 8 muestra la Carga de Intercambio de Claves. Los campos de la Carga de Intercambio de Claves se definen de la siguiente forma: o Carga siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Datos del intercambio de claves ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 8: Formato de la Carga de Intercambio de Claves o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud en octetos de la carga actual, incluyendo la cabecera de carga genérica. o Datos del Intercambio de Claves (longitud variable): Datos requeridos para generar una clave de sesión. La interpretación de este dato es especificado por el DOI y por el algoritmo de Intercambio de Claves asociado. Este campo también puede contener indicadores de claves pre-ubicadas [pre-placed]. El tipo de carga para la Carga de Intercambio de Claves es cuatro (4) Maughan, et. al. Pila de Estándares [Pág. 34] RFC 2408 ISAKMP Noviembre 1998 3.8 Carga de Identificación La Carga de Identificación contiene datos específicos del DOI usados para intercambiar información de identificación. Esta información es usada para determinar las identidades de los usuarios de la comunicación y puede ser usada para determinar la autentificación de la información. La Figura 9 muestra el formato de la Carga de Identificación. Los campos de la Carga de identificación se definen de la siguiente forma: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): La longitud en octetos de la carga actual, incluyendo la cabecera de carga genérica. o Tipo de Identificador (1 octeto): especifica el tipo de Identificación que se está usando. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Tipo de ID ! Datos del Identificador Especifico del DOI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Datos de Identificación ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 9: Formato de la Carga de Identificación Este campo es dependiente del DOI o Datos del Identificador Especifico del DOI (3 octetos): Contiene los datos de Identificación específicos del DOI. Si este campo no es usado, DEBE contener ceros. o Datos de Identificación (Longitud variable): contiene información de identidad. Los valores para este campo son específicos del DOI y el formato es especificado por el campo Tipo de Identificador. Maughan, et. al. Pila de Estándares [Pág. 35] RFC 2408 ISAKMP Noviembre 1998 Los detalles específicos para los Datos de Identificación del DOI de Seguridad IP de la IETF se detallan en [IPDOI]. El tipo de carga para la Carga de Identificación es cinco (5). 3.9 Carga de Certificado La Carga de Certificado proporciona un medio para trasportar certificados o otra certificación relacionada con la información vía ISAKMP y puede aparecer en cualquier mensaje ISAKMP. Las cargas de Certificado DEBERÍAN estar incluidas en un intercambio siempre que un apropiado servicio de directorio (por ejemplo DNS seguros [DNSSEC]) no esté disponible para distribuir los certificados. La Carga de Certificado DEBE ser aceptada en cualquier momento durante el intercambio. La Figura 10 muestra el formato de la Carga de Certificado. NOTA: Los tipos de Certificados y formatos, generalmente no están ligados a un DOI. Se espera que existan solamente pocos tipos de certificaciones, y que la mayoría de los DOIs acepten estos tipos. Los campos de la Carga de Certificado están definidos de la siguiente manera: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Codi. del Certi! ! +-+-+-+-+-+-+-+-+ ! ~ Datos del Certificado ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 10: Formato de la Carga de Certificado. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud en octetos de la carga actual, incluyendo la cabecera de carga genérica. Maughan, et. al. Pila de Estándares [Pág. 36] RFC 2408 ISAKMP Noviembre 1998 o Codificación del Certificado (1 octeto): Este campo indica el tipo de certificado o certificados relacionados a la información contenida en el campo de Datos del Certificado. Tipos de Certificado Valor Ninguno 0 PKCS Nº7 encapsulado en certificados X.509 1 Certificados PGP 2 Clave designada por DNS 3 Certificados X.509-firma 4 Certificados X.509-intercambio de claves 5 Tokens Kerberos 6 Lista de Revocación de Certificados (CRL) 7 Lista de Revocación de Autoridad (ARL) 8 Certificados SPKI 9 Certificados X.509- Atributos 10 RESERVADO 11-255 o Datos del certificado (longitud variable): Codificación actual de los datos del certificado. El tipo de certificación está indicado por el campo Codificación del Certificado. El tipo de carga para la Carga de Certificado es seis (6). 3.10 Carga de Solicitud de Certificado La Carga de solicitud de Certificado proporciona un medio para solicitar certificados vía ISAKMP y puede aparecer en cualquier mensaje. Las cargas de solicitud de Certificado DEBERÍAN estar incluidas en un intercambio siempre que un apropiado servicio de directorio (por ejemplo DNS seguros [DNSSEC]) no este disponible para distribuir los certificados. La carga de Solicitud de Certificado DEBE ser aceptada durante cualquier momento del intercambio. El respondedor de la carga de Solicitud de Certificado DEBE enviar su certificado, en el caso de que los certificados sean soportados, basados en los valores contenidos en la carga. Si múltiples certificados son requeridos, múltiples cargas de Solicitud de Certificados DEBERÍAN ser enviadas. La Figura 11 muestra el formato de la Carga de Solicitud de Certificado. Maughan, et. al. Pila de Estándares [Pág. 37] RFC 2408 ISAKMP Noviembre 1998 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Tipo de Certif ! ! +-+-+-+-+-+-+-+-+ ! ~ Autoridad de Certificación ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 11: Formato de la Carga de solicitud de Certificado Los campos de carga de Solicitud de Certificado son los siguientes: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): la longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. o Tipo de Certificado (1 octeto): contiene una codificación del tipo de certificado requerido. Valores aceptables se encuentran en la Sección 3.9. o Autoridad de Certificación (longitud variable): Contiene una codificación de una autoridad de certificados aceptables para el tipo de certificado solicitado. Como un ejemplo, para un certificado X.509 este campo contendrá la codificación del Nombre Distintivo del Nombre de la Entidad Emisora de una autoridad de certificación X.509 aceptable por el emisor de esta carga. Esta sería incluida para asistir al respondedor en la determinación de cuánto de esa cadena de certificación necesitaría ser enviada en respuesta a esta solicitud. Si no hay una autoridad de certificación específica requerida, este campo no DEBERÍA ser incluido. El tipo de carga para la Carga de solicitud de Certificado es siete (7). 3.11 Carga Hash La Carga Hash contiene los datos generados por la función hash (seleccionada durante el intercambio del establecimiento de la SA), sobre una cierta parte del mensaje y/o del estado de ISAKMP. Esta Maughan, et. al. Pila de Estándares [Pág. 38] RFC 2408 ISAKMP Noviembre 1998 carga puede ser usada para verificar la integridad de los datos en un mensaje ISAKMP, o para la autentificación de las entidades de la negociación. La Figura 12 muestra el formato de la Carga Hash. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Datos Hash ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 12: Formato de la carga Hash. Los campos de la Carga de Hash se definen de la siguiente manera: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): la longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. o Datos Hash (longitud variable): Datos que resultad de aplicar la rutina de hash para el mensaje ISAKMP y/o su estado. El tipo de carga para la Carga Hash es ocho (8). 3.12 Carga de la Firma La Carga de la Firma contiene generalmente datos para la función de la firma digital (seleccionadas durante el intercambio del establecimiento de la SA), sobre cierta parte del mensaje y/o del estado de ISAKMP. Esta carga es usada para verificar la integridad de los datos en un mensaje ISAKMP y puede ser usada para servicios de no repudio. La Figura 13 muestra el formato de la Carga de la Firma. Maughan, et. al. Pila de Estándares [Pág. 39] RFC 2408 ISAKMP Noviembre 1998 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Datos de la Firma ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 13: Formato de la Carga de la Firma Los campos de la Carga de la Firma se definen de la siguiente manera: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. o Datos de la Firma (longitud variable): Los datos que resultan de aplicar la función de una firma digital al mensaje y/o estado de ISAKMP. El tipo de carga para la Carga de la Firma es nueve (9). 3.13 Carga Nonce La Carga Nonce contiene información aleatoria para garantizar la vida de la conexión durante un intercambio y para proteger contra ataques de reenvío. La Figura 14 muestra el formato de la Carga Nonce. Si el nonce es usado para un intercambio de clave particular, el uso de la carga nonce será dictaminado por el intercambio de claves. El nonce puede ser trasmitido como parte de los datos del intercambio de claves, o como una carga separada. Sin embargo, esta es definida por el intercambio de claves, y no por ISAKMP. Maughan, et. al. Pila de Estándares [Pág. 40] RFC 2408 ISAKMP Noviembre 1998 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Datos del Nonce ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 14: Formato de la Carga Nonce Los campos de la Carga Nonce son definidos de la siguiente manera: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. o Datos del Nonce (longitud variable): contiene información aleatoria generada por la entidad transmisora. El tipo de carga para la Carga Nonce es diez (10). 3.14 Carga de Notificación La Carga de Notificación puede incluir datos ISAKMP y datos específicos del DOI y se utiliza para trasmitir datos informativos, tales como condiciones de error, en entidades pares de ISAKMP. Es posible enviar múltiples cargas de Notificación en un único mensaje ISAKMP. La Figura 15 muestra el formato de la Carga de Notificación. La notificación que ocurre durante, o que se refiere a, la negociación de la Fase 1 es identificada por el par de cookies del Iniciador y del Respondedor en la Cabecera de ISAKMP. El Identificador de Protocolo, en este caso, es ISAKMP y el valor del SPI es cero porque el par de cookies en la Cabecera ISAKMP identifican a la SA ISAKMP. Si la notificación ocurre antes de que se haya completado el intercambio de información de las claves, entonces la Notificación estará desprotegida. La notificación que ocurre durante, o se refiere a, la Fase 2 de la negociación es identificada por el par de cookies del Iniciador y del Respondedor en la Cabecera de ISAKMP y el Identificador de Mensajes y Maughan, et. al. Pila de Estándares [Pág. 41] RFC 2408 ISAKMP Noviembre 1998 el SPI asociados con la negociación actual. Un ejemplo de este tipo de notificación es usado para indicar por qué una propuesta fue rechazada. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Dominio de Interpretación (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID-Protocolo !Tamaño del SPI !Tipo de Mensaje de Notificación! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Índice de Parámetros de Seguridad (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Datos de Notificación ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 15: Formato de la Carga de Notificación Los campos de la Carga de Notificación se definen de la siguiente manera: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. o Dominio de Interpretación (4 octetos): Identifica el DOI (como está descripto en la Sección 2.1) bajo el cual esta notificación esta tomando lugar. Para ISAKMP este valor es cero (0) y para el DOI IPsec es uno (1). Otros DOIs pueden ser definidos usando la descripción del Apéndice B. o Identificador de Protocolo (1 octeto): Especifica el identificador del protocolo para la notificación actual. Ejemplo pueden incluir ISAKMP, ESP IPsec, AH IPsec, OSPF, TLS, etc. Maughan, et. al. Pila de Estándares [Pág. 42] RFC 2408 ISAKMP Noviembre 1998 o Tamaño del SPI (1 octeto): La longitud en octetos del SPI como es definido por el Identificador de Protocolo. En el caso de ISAKMP, el par de cookies del Iniciador y del Respondedor de la Cabecera ISAKMP es el SPI de ISAKMP, por lo tanto, el Tamaño del SPI es irrelevante y PUEDE variar desde cero (0) a dieciséis (16). Si el Tamaño del SPI no es cero, el contenido del campo del SPI DEBE ser ignorado. El Dominio de Interpretación (DOI) determinará el tamaño del SPI para otros protocolos. o Tipo de Mensaje de Notificación (2 octetos): Especifica el tipo de mensaje de notificación (ver Sección 3.14.1). Textos adicionales, si es especificado por el DOI, son colocados en el campo de Datos de Notificación. o SPI (longitud variable): Índice de Parámetros de Seguridad. El SPI de la entidad receptora. El uso del campo SPI se describió en la Sección 2.4. La longitud de este campo es determinada por el campo de Tamaño del SPI y no necesariamente se debe alinear a límites de 4 octetos. o Datos de Notificación (longitud variable): Datos informativos o de error trasmitidos además del Tipo de Mensaje de Notificación. Los valores para este campo son específicos del DOI El tipo de carga para la Carga de Notificación es once (11). 3.14.1 Tipos de Mensaje de Notificación La información de notificación puede tener mensajes de error especificando por qué una SA no pudo ser establecida. También puede tener datos de estado para que un manejador de procesos en una base de datos de SA pueda comunicarse con los procesos pares. Por ejemplo, una interfaz de usuario segura [secure front end] o un security gateway pueden usar el Mensaje de Notificación para sincronizar la comunicación de SA. La tabla siguiente enumera los tipos de Mensajes de Notificación y sus valores correspondientes. Los valores en el rango de Uso Privado se espera que sean valores específicos del DOI. Maughan, et. al. Pila de Estándares [Pág. 43] RFC 2408 ISAKMP Noviembre 1998 MENSAJES DE NOTIFICACIÓN - TIPOS DE ERRORES Errores Valor TIPO DE CARGA NO VÁLIDA 1 DOI NO SOPORTADO 2 SITUACIÓN NO SOPORTADA 3 COOKIE NO VÁLIDO 4 VERSIÓN MAYOR NO VÁLIDA 5 VERSIÓN MENOR NO VÁLIDA 6 TIPO DE INTERCAMBIO NO BALIDO 7 BANDERAS NO VALIDAS 8 IDENTIFICADOR DE MENSAJE NO VÁLIDO 9 IDENTIFICADOR DE PROTOCOLO NO VÁLIDO 10 SPI NO VÁLIDO 11 IDENTIFICADOR DE TRANSFORMACIÓN NO VÁLIDO 12 ATRIBUTOS NO SOPORTADOS 13 ELECCIÓN DE LA PROPUESTA NO VÁLIDA 14 SINTAXIS DE LA PROPUESTA DEFICIENTE 15 CARGA MAL FORMADA 16 INFORMACIÓN DE CLAVE NO VÁLIDA 17 INFORMACIÓN DEL IDENTIFICADOR NO VÁLIDO 18 CODIFICACIÓN DE CERTIFICADO NO VÁLIDO 19 CERTIFICADO NO VÁLIDO 20 TIPO DE CERTIFICADO NO SOPORTADO 21 AUTORIDAD DE CERTIFICACIÓN NO VÁLIDA 22 INFORMACIÓN DE HASH NO VÁLIDA 23 ERROR EN LA AUTENTIFICACIÓN 24 FIRMA NO VÁLIDA 25 NOTIFICACIÓN DE DIRECCIÓN 26 NOTIFICACIÓN DE TIEMPO DE VIDA DE LA SA 27 CERTIFICADO NO DISPONIBLE 28 TIPO DE INTERCAMBIO NO SOPORTADO 29 RESERVAD (Uso Futuro) 31-8191 USO PRIVADO 8192-16383 MENSAJE DE NOTIFICACIÓN - TIPOS DE STATUS Estado Valor CONECTADO 16384 RESERVADO (Uso Futuro) 16385 - 24575 Códigos específicos de DOI 24576 - 32767 USO PRIVADO 32768 - 40959 RESERVADO (Uso futuro) 40960 - 65535 Maughan, et. al. Pila de Estándares [Pág. 44] RFC 2408 ISAKMP Noviembre 1998 3.15 Carga de Cancelación La Carga de Cancelación contiene un identificador de SA específico de un protocolo que el emisor ha revocado para esta base de datos de SA y por consiguiente ya no es válida. La Figura 16 muestra el formato de la Carga de Cancelación. Es posible enviar múltiples SPIs en una carga de Cancelación, sin embargo, cada SPI DEBE ser del mismo protocolo. La mezcla de identificadores de protocolo NO DEBE ser realizada en la carga de Cancelación. La cancelación concerniente a una SA ISAKMP contendrá un Identificador de Protocolo de ISAKMP y los SPIs son las cookies del Iniciador y Respondedor de la Cabecera de ISAKMP. La cancelación concerniente a una SA de Protocolo, tales como ESP o AH, contendrán el Identificador de Protocolo de ese protocolo (por ejemplo ESP, AH) y la SPI son las SPIs de la entidades emisoras. Nota: La Carga de Cancelación no es una solicitud del respondedor para cancelar una SA, sino que es una notificación del iniciador al respondedor. Si el respondedor elige ignorar el mensaje, la siguiente comunicación del respondedor al iniciador, que use esa SA, fallará. Se espera que un respondedor reconozca el acuse de recibo de la carga de Cancelación. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! RESERVADO ! Longitud de la Carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Dominio de Interpretación (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID-Protocolo !Tamaño del SPI ! Número de SPIs ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Índice(s) de Parámetros de Seguridad (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 16: Formato de la Carga de Cancelación Los campos de la Carga de Cancelación se definen de la siguiente manera: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. Maughan, et. al. Pila de Estándares [Pág. 45] RFC 2408 ISAKMP Noviembre 1998 o Longitud de la Carga (2 octetos): Longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. o Dominio de Interpretación (4 octetos): Identifica el DOI (como se describe en la Sección 2.1) bajo el cual esta cancelación esta tomando lugar. Para ISAKMP este valor es cero (0) y para el DOI IPsec es uno (1). Otros DOIs pueden ser definidos usando la descripción del Apéndice B o Identificador de Protocolo (1 octeto): ISAKMP puede establecer SA para varios protocolos, incluyendo ISAKMP y IPsec. Este campo identifica a qué base de datos de asociaciones de seguridad (SAD) se aplicará la solicitud de cancelación. o Tamaño del SPI (1 octeto): Longitud en octetos del SPI como esta definido por el Identificador de Protocolo. En el caso de ISAKMP, el par de cookies del Iniciador y del Respondedor es el SPI de ISAKMP. En este caso el Tamaño del SPI sería de 16 octetos para cada uno de los SPI que están siendo cancelados. o Número de SPIs (2 octetos): El número de SPIs contenidos en la Carga de Cancelación. El tamaño de cada SPI es definido por el campo Tamaño del SPI. o Índice(s) de parámetros de seguridad (longitud variable): identifica la SA(s) que serán canceladas. Los valores para este campo están en el DOI y protocolo especifico. La longitud de este campo es determinada por los campos Tamaño del SPI y Número de SPIs. El tipo de carga para la carga de Cancelación es doce (12) 3.16 Carga de Identificador del Vendedor La Carga de Identificador del Vendedor contiene una constante definida por el vendedor. La constante es usada por los vendedores para identificar y reconocer instancias remotas de sus aplicaciones. Este mecanismo permite a un vendedor experimentar nuevas características, manteniendo la compatibilidad. Esto no es una habilidad de ISAKMP. La Figura 17 muestra la Carga de Identificación de Vendedor. La carga de Identificación del Vendedor no es un anuncio de que el emisor enviará tipos de cargas privadas. Un vendedor que envía un Identificador de vendedor no DEBE hacer ninguna conjetura sobre cargas privadas que podrían ser enviadas a menos que un Identificador de Vendedor sea también recibido. Múltiples cargas de Identificador Maughan, et. al. Pila de Estándares [Pág. 46] RFC 2408 ISAKMP Noviembre 1998 de Vendedor PUEDEN ser enviadas. Una implementación NO REQUIERE comprender las cargas de Identificación de Vendedor. Una implementación NO REQUIERE enviar todas las cargas de Identificación de Vendedor. Si una carga privada fue enviada, sin acuerdo previo, una implementación puede rechazar una propuesta con un mensaje de notificación TIPO DE CARGA NO VÁLIDA. Si una Carga de Identificador de Vendedor es enviada, esta DEBE ser enviada durante la primera fase de la negociación. La recepción de una carga de Identificador de Vendedor familiar en la fase uno de la negociación permite que una implementación haga uso de los números de carga de Uso Privado (128 a 255), descriptos en la Sección 3.1 para extensiones especificas del vendedor durante la fase dos de la negociación. La definición de "familiar" se usa para determinar implementaciones. Algunos vendedores pueden desear implementar otras extensiones de vendedor antes de la estandarización. No obstante, esta práctica no DEBERÍA difundirse y los vendedores deben trabajar hacia una estandarización. La constante definida por el vendedor DEBE ser única. La elección del hash y el texto a hashiar la decide el vendedor. Como ejemplo, los vendedores pueden generar su identificador de vendedor tomando un simple hash de la cadena de caracteres que contiene el nombre del producto, y la versión del producto. Un hash es usado en lugar de un registro de vendedor para evitar problemas de políticas criptográficas locales con listas de productos "aprobados", para evitar tener una lista de vendedores, y permitiendo evitar que productos clasificados aparezcan en alguna lista. Por ejemplo: "Compañía IPsec. Versión 97.1" (no incluido textualmente) Tiene un hash MD5 igual a: 48544f9b1fe662af98b9b39e50c01a5a, cuando se usa MD5FILE. Los vendedores pueden incluir todo el hash, o solo una parte, como parte de los datos de la carga. Hay implementaciones de seguridad de este hash por lo tanto su elección es arbitraria. Maughan, et. al. Pila de Estándares [Pág. 47] RFC 2408 ISAKMP Noviembre 1998 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Carga Siguiente! Reservado ! Longitud de la carga ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Identificador del vendedor (VID) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 17: Formato de la Carga de Identificador del Vendedor La Carga de Identificación del Vendedor esta definida de la siguiente manera: o Carga Siguiente (1 octeto): Identificador del tipo de carga de la siguiente carga en el mensaje. Si la carga actual es la última en el mensaje, este campo contendrá el valor cero. o RESERVADO (1 octeto): No utilizado, debe contener ceros. o Longitud de la Carga (2 octetos): Longitud de la carga actual en octetos, incluyendo la cabecera de carga genérica. o Identificador del vendedor (longitud variable): Hash de la cadena de caracteres del vendedor más la versión (como se describió arriba). El tipo de carga para la Carga de Identificador del Vendedor es trece (13). 4 Intercambios ISAKMP ISAKMP proporciona la sintaxis básica para el intercambio de un mensaje. Los bloques básicos de construcción para los mensajes ISAKMP son los tipos de carga descriptos en la Sección 3. Esta sección describe los procedimientos para el establecimiento y modificación de SAs, seguidos de un conjunto de intercambios por defecto que PUEDEN ser usados para una interoperatibilidad inicial. Otros intercambios serán definidos teniendo en cuenta el DOI y el intercambio de claves. El [IPDOI] y el [IKE] son ejemplos de cómo esto es logrado. El Apéndice B explica los procedimientos para lograr estas inclusiones. 4.1 Tipos de Intercambios ISAKMP ISAKMP permite la creación de intercambios para el establecimiento de SA y material claves. Hay actualmente 5 Tipos de Intercambio por Maughan, et. al. Pila de Estándares [Pág. 48] RFC 2408 ISAKMP Noviembre 1998 defecto definidos por ISAKMP. Desde la Sección 4.4 hasta la Sección 4.8 se describen estos intercambios. Los intercambios definen los contenidos y el ordenamiento de los mensajes ISAKMP entre usuarios. La mayoría de los intercambios incluirán todos los tipos de cargas básicas - SA, KE, ID, SIG, y pueden incluir otros. La diferencia principal entre los tipos de intercambio es el ordenamiento de los mensajes y el ordenamiento de las cargas dentro de cada mensaje. Mientras que el ordenamiento de las cargas dentro de los mensajes no esta definido, para el procesamiento eficiente se RECOMIENDA que la carga de SA sea la primer carga dentro de un intercambio. El procesamiento de cada carga dentro de un intercambio se describe en la Sección 5. Desde la Sección 4.4 hasta la Sección 4.8 se ofrece un conjunto de intercambios ISAKMP por defecto. Estos intercambios proporcionan diferentes protecciones de seguridad para el intercambio mismo y la información intercambiada. Los diagramas en cada una de las siguientes secciones muestran el ordenamiento del mensaje para cada tipo de intercambio, como así también las cargas incluidas en cada mensaje, y proporcionan notas básicas que describen que ha sucedido después de cada mensaje intercambiado. Ninguno de estos ejemplos incluyen "cargas opcionales", como por ejemplo certificados o solicitud de certificado. Además, ninguno de estos ejemplos incluye un intercambio inicial de las cabeceras de ISAKMP (conteniendo las cookies del iniciador y del respondedor) que proporcionarían protección contra saturación (ver Sección 2.5.3). Los intercambios definidos no pretenden satisfacer todos los requerimientos del DOI y de los protocolos de intercambio de claves. Si los intercambios definidos satisfacen los requerimientos del DOI, podrían ser usados como se explicó. Si los intercambios definidos no satisfacen los requerimientos de seguridad definidos por el DOI, el DOI DEBE especificar nuevos tipos de intercambio y las secuencias válidas de las cargas que hacen un intercambio exitoso, y como construir y interpretar estas cargas. Todas las implementaciones de ISAKMP DEBEN implementar Intercambios Informativos y DEBERÍAN implementar los otros 4 intercambios. Sin embargo, esto depende de la definición del DOI y de los protocolos de intercambio asociados. Como se explicó arriba, estos tipos de intercambio pueden ser usados en cualquier fase de la negociación, no obstante, deben proporcionar diferentes propie