Kerberized Internet Negotiation of Keys ( KINK ) es un protocolo definido en RFC 4430 que se utiliza para configurar una asociación de seguridad IPsec (SA), similar a Internet Key Exchange (IKE), que utiliza el protocolo Kerberos para permitir que terceros de confianza manejen la autenticación de pares. y gestión de políticas de seguridad de forma centralizada. [1]
Su motivación se da en RFC 3129 como una alternativa a IKE, en la que los pares deben usar certificados X.509 para la autenticación, usar el intercambio de claves (DH) Diffie-Hellman para el cifrado, conocer e implementar una política de seguridad para cada par con el que se conectará, [2] con autenticación de los certificados X.509 ya sea preestablecidos o usando DNS , preferiblemente con DNSSEC . [3] Al utilizar Kerberos, los pares de KINK solo deben autenticarse mutuamente con el servidor de autenticación (AS) apropiado, con un centro de distribución de claves (KDC) que a su vez controle la distribución del material de claves. para el cifrado y, por tanto, el control de la política de seguridad IPsec.
Descripción del protocolo
KINK es un protocolo de comando / respuesta que puede crear, eliminar y mantener IPsec SA. Cada comando o respuesta contiene un encabezado común junto con un conjunto de cargas útiles de tipo, longitud y valor. El tipo de comando o respuesta limita las cargas útiles enviadas en los mensajes del intercambio.
KINK en sí es un protocolo sin estado en el sentido de que cada comando o respuesta no requiere almacenamiento de estado duro para KINK. Esto contrasta con IKE, que utiliza el modo principal para establecer primero una SA de protocolo de administración de claves y asociación de seguridad de Internet ( ISAKMP ) seguida de los siguientes intercambios de modo rápido.
KINK utiliza mecanismos de Kerberos para proporcionar autenticación mutua y protección de reproducción. Para establecer SA, KINK proporciona confidencialidad para las cargas útiles que siguen a la carga útil AP-REQ de Kerberos. El diseño de KINK mitiga los ataques de denegación de servicio al requerir intercambios autenticados antes del uso de cualquier operación de clave pública y la instalación de cualquier estado. KINK también proporciona un medio para utilizar los mecanismos de usuario a usuario de Kerberos cuando no hay una clave compartida entre el servidor y el KDC. Este es típicamente, pero no se limita a, el caso de los pares IPsec que utilizan PKINIT para la autenticación inicial.
KINK reutiliza directamente las cargas útiles del modo rápido definidas en la sección 5.5 de IKE , con algunos cambios y omisiones menores. En la mayoría de los casos, los intercambios de KINK son un solo comando y su respuesta. Se requiere un tercer mensaje opcional al crear SA, solo si el respondedor rechaza la primera propuesta del iniciador o desea contribuir con los materiales de codificación. KINK también proporciona cambio de claves y detección de pares muertos .
Formato de paquete
El mensaje KINK incluye los siguientes campos:
Desplazamiento de bits | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | tipo | versión | largo | |||||||||||||||||||||||||||||
32 | dominio de interpretación (DOI) | |||||||||||||||||||||||||||||||
64 | ID de transacción (XID) | |||||||||||||||||||||||||||||||
96 | siguiente carga útil | A | longitud de la suma de control | |||||||||||||||||||||||||||||
128 ... | cargas útiles ... | |||||||||||||||||||||||||||||||
... ... | suma de comprobación ... |
- tipo: CREAR, ELIMINAR, RESPONDER, OBTENER, ACK, ESTADO o uso privado
- versión: el número de versión del protocolo principal
- length: longitud de todo el mensaje
- dominio de interpretación (DOI): un DOI según se define en el Protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP)
- ID de transacción (XID): identificación de la transacción, definida como un comando, una respuesta y un acuse de recibo opcional
- siguiente carga útil: tipo de la primera carga útil después del encabezado del mensaje como KINK_DONE, KINK_AP_REQ, KINK_AP_REP, KINK_KRB_ERROR, KINK_TGT_REQ, KINK_TGT_REP, KINK_ISAKMP, KINK_ENCRYPT o KINK_ERROR
- ACK o ACKREQ bit: 1 si el respondedor requiere un reconocimiento explícito de que se recibió una RESPUESTA; de lo contrario, 0
- longitud de la suma de comprobación: longitud en bytes de la suma de comprobación criptográfica del mensaje
- cargas útiles: una lista de cargas útiles de tipo / longitud / valor (TLV)
- suma de comprobación: suma de comprobación con clave Kerberos sobre todo el mensaje, excluyendo el campo de suma de comprobación en sí
Cargas útiles
Las cargas útiles de KINK se definen como:
Desplazamiento de bits | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | siguiente carga útil | longitud de carga útil | ||||||||||||||||||||||||||||||
32 ... | valor ... |
- siguiente carga útil: tipo de la primera carga útil
- length: longitud de la carga útil
Se definen las siguientes cargas útiles:
- KINK_AP_REQ: una carga útil que transmite un AP-REQ de Kerberos al respondedor
- KINK_AP_REP: una carga útil que transmite un AP-REP de Kerberos al iniciador
- KINK_KRB_ERROR: una carga útil que transmite errores de tipo Kerberos al iniciador
- KINK_TGT_REQ: una carga útil que proporciona un medio para obtener un TGT del par con el fin de obtener un ticket de servicio de usuario a usuario del KDC
- KINK_TGT_REP: una carga útil que contiene el TGT solicitado en una carga útil KINK_TGT_REQ anterior de un comando GETTGT
- KINK_ISAKMP: una carga útil para encapsular las cargas útiles de ISAKMP IKE Quick Mode (fase 2), para permitir la compatibilidad con versiones anteriores de IKE e ISAKMP si hay revisiones posteriores
- KINK_ENCRYPT: una carga útil para encapsular otras cargas útiles KINK y se cifra mediante la clave de sesión y el algoritmo especificado por su tipo
- KINK_ERROR: una carga útil que devuelve una condición de error
Implementaciones
Las siguientes implementaciones de código abierto de KINK están disponibles actualmente:
- Racoon2 del proyecto WIDE .
Ver también
Referencias
- ^ RFC 3129: Requisitos para la negociación de claves de Internet kerberizada , Grupo de trabajo de ingeniería de Internet , junio de 2001, p. 2
- ^ RFC 3129: Requisitos para la negociación de claves en Internet kerberizada , Grupo de trabajo de ingeniería de Internet , junio de 2001, p. 1
- ^ RFC 4322: Cifrado oportunista mediante el intercambio de claves de Internet (IKE) , Grupo de trabajo de ingeniería de Internet , junio de 2001, p. 5