The Cable GuyEl protocolo de Internet autenticado

Joseph Davies

Algunas partes de esta columna analizan una versión preliminar de Windows Server 2008. Dichos comentarios están sujetos a cambios.

Tanto Windows Vista como Windows Server 2008 (que ahora se encuentra en fase de prueba de la versión beta) admiten el protocolo de Internet autenticado (AuthIP), una versión mejorada del protocolo de intercambio de claves por red (IKE). Tanto AuthIP como IKE son protocolos usados para determinar material de claves y negociar parámetros de seguridad para comunicaciones protegidas mediante

protocolo de seguridad de Internet (IPsec). AuthIP ofrece configuración y mantenimiento simplificados de directivas de IPsec en muchas configuraciones y flexibilidad adicional para la autenticación de IPsec en el mismo nivel. Este artículo describe los detalles del protocolo AuthIP y los comportamientos de coexistencia entre interlocutores IPsec del mismo nivel que admiten AuthIP e IKE o sólo IKE.

Información general de IKE

Ejemplos de negociación

Para demostrar el comportamiento de coexistencia, examinemos lo que sucede entre interlocutores IPsec del mismo nivel basados en Windows Vista y Windows XP al intentar negociar la protección de IPsec.

Ejemplo 1: Dos interlocutores IPsec en modo de solicitud basados en Windows Vista

En este ejemplo, un IPsec del mismo nivel basado en Windows Vista (Peer 1) es el iniciador, y el respondedor ejecuta Windows Vista (Peer 2). Ambos sistemas del mismo nivel se configuran con modo de solicitud para comunicaciones entrantes y salientes. En modo de solicitud, un IPsec del mismo nivel solicita protección pero no la necesita. Los mensajes se intercambian de la siguiente manera:

1. Peer 1 envía un segmento TCP Sincronizar (SYN) de texto no cifrado, e inicia una conexión TCP con Peer 2.
2. Peer 2 envía un segmento de acuse de recibo de TCP SYN (ACK).
3. Peer 1 envía un segmento TCP ACK.
4. Peer 1 envía un mensaje ISAKMP basado en AuthIP e inicia una negociación de modo principal de AuthIP.
5. Peer 1 envía un mensaje ISAKMP basado en IKE, e inicia una negociación de modo principal de IKE.
6. Peer 2 responde con un mensaje ISAKMP basado en AuthIP y continúa una negociación de modo principal de AuthIP.
7. Peer 1 y Peer 2 completan negociaciones de modo principal, modo rápido y modo extendido (opcional).
8. Los segmentos siguientes que se envían por la conexión TCP están protegidos con IPsec.

El orden exacto de los mensajes del 1 al 5 depende de la latencia de la red. Los ejemplos descritos en este artículo se aplican a una red de muy baja latencia, en que el protocolo de enlace TCP (mensajes 1 a 3) se completa antes de que Peer 1 pueda enviar los mensajes ISAKMP iniciales (mensajes 4 y 5). En una red con mayor latencia, observará que Peer 1 envía el segmento TCP SYN de texto no cifrado, el mensaje ISAKMP basado en AuthIP y, a continuación, el mensaje ISAKMP basado en IKE como los primeros tres mensajes del intercambio de mensajes.

Ejemplo 2: Un IPsec del mismo nivel en modo de solicitud basado en Windows Vista y un IPsec del mismo nivel en modo de solicitud basado en Windows XP

En este ejemplo, un IPsec del mismo nivel basado en Windows Vista (Peer 1) es el iniciador y el respondedor ejecuta Windows XP (Peer 2). Ambos sistemas del mismo nivel se configuran con modo de solicitud para comunicaciones entrantes y salientes. Los mensajes se intercambian de la siguiente manera:

1. Peer 1 envía un segmento TCP SYN de texto no cifrado, e inicia una conexión TCP con Peer 2.
2. Peer 2 envía un segmento SYN-ACK TCP.
3. Peer 1 envía un segmento TCP ACK.
4. Peer 1 envía un mensaje ISAKMP basado en AuthIP e inicia una negociación de modo principal de AuthIP.
5. Peer 1 envía un mensaje ISAKMP basado en IKE, e inicia una negociación de modo principal de IKE.
6. Peer 2 responde con un mensaje ISAKMP basado en IKE y continúa la negociación de modo principal de IKE.
7. Peer 1 y Peer 2 completan las negociaciones de modo principal y de modo rápido de IKE.
8. Los segmentos siguientes que se envían por la conexión TCP están protegidos con IPsec.

Ejemplo 3: Un IPsec del mismo nivel en modo de solicitud basado en Windows Vista y un IPsec del mismo nivel en modo de requerir basado en Windows XP

En este ejemplo, un IPsec del mismo nivel basado en Windows Vista (Peer 1) es el iniciador y el respondedor ejecuta Windows XP (Peer 2). Peer 1 se configura con modo de solicitud para comunicaciones salientes y Peer 2 se configura con modo de requerir para comunicaciones entrantes. En modo de requerir, un IPsec del mismo nivel requiere protección de IPsec y descarta de modo silencioso los paquetes sin protección. Los mensajes se intercambian de la siguiente manera:

1. Peer 1 envía un segmento TCP SYN de texto no cifrado, e inicia una conexión TCP, que Peer 2 descarta de modo silencioso.
2. Peer 1 envía un mensaje ISAKMP basado en AuthIP, e inicia una negociación de modo principal de AuthIP, que Peer 2 descarta de modo silencioso.
3. Peer 1 envía un mensaje ISAKMP basado en IKE, e inicia una negociación de modo principal de IKE.
4. Peer 2 responde con un mensaje ISAKMP basado en IKE y continúa la negociación de modo principal de IKE.
5. Peer 1 y Peer 2 completan las negociaciones de modo principal y de modo rápido de IKE.
6. Peer 1 retransmite el segmento TCP SYN (protegido con IPsec).
7. Peer 2 envía el segmento TCP SYN-ACK (protegido con IPsec).
8. Peer 1 envía el segmento TCP ACK (protegido con IPsec).

IKE es un estándar de Internet, definido en RFC 2409 (ietf.org/rfc/rfc2409.txt), que define un mecanismo para establecer asociaciones de seguridad (SA) de IPsec. Una SA es una combinación de una directiva de mutuo acuerdo y claves que definen servicios y mecanismos de seguridad que ayudan a proteger la comunicación entre interlocutores IPsec. Específicamente, IKE combina la asociación de seguridad de Internet y el protocolo de administración de claves (ISAKMP) en RFC 2408 y Oakley Key Determination Protocol (RFC 2412). IKE usa Oakley Key Determination Protocol para generar el material de clave secreto para comunicaciones protegidas.

IKE usa ISAKMP para negociar las SA. ISAKMP incluye componentes para identificar y autenticar sistemas del mismo nivel, administrar las SA y cambiar el material de clave. ISAKMP es un marco para negociar comunicaciones protegidas independiente de los protocolos específicos de intercambio de claves, de los algoritmos de cifrado e integridad y de los métodos de autenticación.

Los interlocutores IPsec usan IKE para realizar negociaciones de modo principal y modo rápido de IKE. La negociación de modo principal crea la SA de ISAKMP, que protege negociaciones de seguridad. Durante la negociación de modo principal, el iniciador y el respondedor intercambian una serie de mensajes ISAKMP para negociar los algoritmos de cifrado y hash para la SA de ISAKMP, intercambian material de determinación de claves y se identifican y autentican entre sí.

En la fase de negociación de modo rápido, se crean las dos SAs de IPsec (una SA para datos entrantes y otra para datos salientes), que protegen los datos enviados entre dos interlocutores IPsec. Durante la negociación de modo rápido, el iniciador y el respondedor intercambian una serie de mensajes ISAKMP cifrados para negociar los algoritmos de cifrado y hash para las SA de IPsec entrantes y salientes.

Para obtener más información acerca de las negociaciones de modo principal y modo rápido basadas en IKE, consulte "Negociación IKE para asociaciones de seguridad de IPsec" en microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Información general de AuthIP

AuthIP es una versión mejorada de IKE que ofrece flexibilidad adicional con compatibilidad para autenticación basada en usuario, autenticación con múltiples credenciales, negociación mejorada de métodos de autenticación y autenticación asimétrica. Como IKE, AuthIP es compatible con las negociaciones de modo principal y modo rápido. AuthIP también es compatible con el modo extendido, una parte de la negociación de un IPsec del mismo nivel durante la cual se puede realizar una segunda ronda de autenticación. El modo extendido, que es opcional, se puede usar para varias autenticaciones. Por ejemplo, con el modo extendido puede realizar autenticaciones independientes basadas en equipo y en usuario.

La compatibilidad con autenticación múltiple forma parte del cumplimiento de IPsec para la plataforma de protección de acceso a redes (NAP), en la que los interlocutores de IPsec se autentican con credenciales de equipo y también usan un certificado de mantenimiento para demostrar que son compatibles con los requisitos de mantenimiento de sistema. Para obtener más información acerca de la protección de acceso a redes, consulte microsoft.com/nap. Y para obtener información adicional acerca de las características de AuthIP, consulte "AuthIP en Windows Vista " en microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Mensajes AuthIP

Tanto IKE como AuthIP usan ISAKMP para su intercambio de claves y como protocolo de negociación de SA. Los mensajes ISAKMP se envían mediante el protocolo de datagrama de usuario (UDP) y se componen de un encabezado ISAKMP y una o más cargas ISAKMP. El encabezado ISAKMP contiene información acerca del mensaje, que incluye el tipo de mensaje. La figura 1 muestra el formato del encabezado ISAKMP.

Figura 1** Formato del encabezado ISAKMP **

En el encabezado ISAKMP, la cookie del iniciador y la cookie del respondedor se establecen en un número aleatorio distinto de cero elegido por los interlocutores IPsec. El campo Siguiente carga indica la primera carga del mensaje ISAKMP, justo a continuación del encabezado ISAKMP. RFC 2408 enumera los valores definidos del campo Siguiente carga. Los tipos de carga 128-255 están reservados para uso privado. Los campos Versión principal y Versión secundaria indican las versiones de ISAKMP en el IPsec del mismo nivel que envía el mensaje ISAKMP. Para IKE y AuthIP, la versión principal es 1 y la versión secundaria es 0.

El campo Tipo de intercambio indica el tipo de intercambio ISAKMP que se realiza. El tipo de intercambio dicta la estructura y orden de las cargas ISAKMP. RFC 2408 define los valores del campo Tipo de intercambio. Los tipos de intercambio 128-255 están reservados para uso privado.

El campo Marcadores contiene tres marcadores definidos en RFC 2408. El bit menos significativo (bit 0) es el bit Cifrado, que indica que las cargas de ISAKMP están cifradas (cuando se establece en 1) o no cifradas (cuando se establece en 0). El cifrado se realiza mediante el algoritmo negociado por la SA de ISAKMP, identificada por la combinación de los campos Cookie del iniciador y Cookie del respondedor. El siguiente bit menos significativo (bit 1) es el bit Commit, que indica que el intercambio de claves es sincronizado (cuando se establece en 1) o no sincronizado (cuando se establece en 0). El bit Commit se usa para garantizar que la SA completa su negociación antes que se envíen los datos cifrados. El siguiente bit menos significativo (bit 2) es el bit Authentication Only, que se usa para indicar que el mensaje contiene (cuando se establece en 1) o no contiene (cuando se establece en 0) la carga Notify completa del tipo de intercambio informativo y que ha sido autenticada pero no cifrada.

El campo Id. de mensaje contiene un identificador único para el mensaje. El identificador de mensaje se usa para evitar conflictos cuando ambos interlocutores IPsec intentan establecer simultáneamente una SA de IPsec. El campo Longitud indica la longitud del mensaje ISAKMP completo.

Para IKE, el mensaje ISAKMP contiene una serie de cargas ISAKMP. La primera carga se indica con el campo Siguiente carga del encabezado ISAKMP. Cada carga ISAKMP tiene su propio campo Siguiente carga para indicar la carga que sigue. El campo Siguiente carga de la última carga está establecido en 0. La figura 2 muestra el formato de los mensajes IKE.

Figura 2** Formato de mensajes IKE **

AuthIP usa mensajes ISAKMP con tipos de intercambio 243 (modo principal), 244 (modo rápido), 245 (modo extendido) y 246 (Notificar) en el campo Tipo de intercambio del encabezado ISAKMP. Una diferencia importante en los mensajes ISAKMP basados en AuthIP es que sólo contienen una carga ISAKMP: la carga Cifrada o la carga Notificar. La carga Cifrada contiene las cargas incrustadas que se usan en las negociaciones de modo principal, modo rápido o modo extendido. La carga Cifrada puede contener un conjunto de texto sin formato o de cargas cifradas, en función del bit Cifrado del campo Marcadores del encabezado ISAKMP. La figura 3 muestra el formato de mensajes AuthIP que contienen la carga Cifrada.

Figura 3** Formato de mensajes AuthIP que contienen la carga Cifrada **

Coexistencia de AuthIP e IKE

Windows Vista® y Windows Server® 2008 son compatibles con IKE y AuthIP. Sin embargo Windows® XP y Windows Server 2003, sólo son compatibles con IKE. Un IPsec del mismo nivel que se inicia y es compatible con AuthIP e IKE y tiene una directiva de seguridad de conexión que usa AuthIP e IKE debe determinar si el IPsec del mismo nivel que responde es compatible con AuthIP o IKE. A continuación, debe usar el protocolo más apropiado para negociar la protección de IPsec y preferir el uso de AuthIP sobre IKE.

Para determinar el protocolo de negociación del IPsec del mismo nivel que responde, un IPsec del mismo nivel que inicia y que usa AuthIP e IKE envía los siguientes mensajes al mismo tiempo:

• Mensaje 1: un mensaje AuthIP que inicia una negociación de modo principal
• Mensaje 2: un mensaje IKE que inicia una negociación de modo principal

Si el nodo que responde es compatible con AuthIP, debe responder al mensaje 1 con un mensaje AuthIP que continúe la negociación de modo principal y descarte de modo silencioso el mensaje 2. Un nodo que responde y que no es compatible con AuthIP descarta de modo silencioso el mensaje 1 porque el campo Tipo de intercambio contienen un valor que no admite y responde al mensaje 2.

Para evitar la negociación basada en IKE entre dos interlocutores IPsec que ejecutan Windows Vista o Windows Server 2008 cuando el mensaje 1 se pierde en la red o llega después que el mensaje 2, los interlocutores IPsec que ejecutan Windows Vista o Windows Server 2008 envían el mensaje 2 con una carga ISAKMP de identificador de proveedor de AuthIP. La carga Id. de proveedor de AuthIP compatible indica que el IPsec del mismo nivel es compatible con AuthIP.

Por lo tanto, si un IPsec del mismo nivel que ejecuta Windows Vista o Windows Server 2008 recibe el mensaje 2 con la carga Id. de proveedor de AuthIP compatible, espera que el IPsec del mismo nivel que inicia retransmita los mensajes 1 y 2 y responde al mensaje 1.

El IPsec del mismo nivel que inicia sigue retransmitiendo ambos Mensajes 1 y 2 hasta que reciba una respuesta o se agote el tiempo de espera. Cuando el iniciador recibe una respuesta, determina la capacidad del respondedor a partir del encabezado ISAKMP de la respuesta. Si el tipo de intercambio se establece en 243 (que es el tipo de intercambio de una negociación de modo principal basada en AuthIP), el respondedor tiene capacidad AuthIP. Si el Tipo de intercambio se establece en 2 (que es el tipo de intercambio de una negociación de modo principal basada en IKE), el respondedor tiene capacidad IKE.

En función de la respuesta, el iniciador responde con el siguiente mensaje AuthIP a una negociación de modo principal basada en AuthIP o bien con el siguiente mensaje IKE a una negociación de modo principal basada en IKE. Los interlocutores IPsec deben usar el mismo protocolo que se usa para negociar la SA de ISAKMP durante la vigencia de la SA.

Joseph Davieses escritor técnico de Microsoft y autor del artículo mensual Cable Guy de TechNet en Microsoft.com/technet/community/columns/cableguy.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.