Resumen

  • RFC 3129 exigió que las claves de sesión de los tickets Kerberos sirvieran de base para las asociaciones de seguridad IPsec, reduciendo la necesidad de secretos duraderos entre cada pareja de nodos.
  • KINK no se propuso como sustituto de IKE: ganaba administración central y ahorro de cálculo, pero perdía la capacidad de negociar sin un tercero activo.
  • El cambio trasladaba complejidad hacia el KDC, los reinos, el tiempo y la nomenclatura, mientras que la autorización de selectores y túneles seguía siendo local.

Una red pequeña puede repartir secretos a mano y fingir que el problema está resuelto. Una red grande convierte esa costumbre en una matriz. RFC 3129 describió la distribución de claves precompartidas entre pares como un problema O(n²): cada nueva máquina no añade una sola relación, sino muchas posibles relaciones bilaterales. Kerberos ofrecía otra forma. Cada principal mantenía una relación de largo plazo con el Centro de Distribución de Claves, y el KDC emitía tickets con claves de sesión para servicios concretos.

La comparación era deliberadamente esquemática. No incluía todos los gastos de un reino, la recuperación, la rotación o la confianza cruzada. Sin embargo, situó el debate en el lugar correcto. La criptografía no sólo consume ciclos; también crea vínculos que alguien debe inventariar, proteger, renovar y revocar.

IPsec ya disponía de una arquitectura para proteger paquetes. RFC 2401 definía asociaciones de seguridad y los papeles de AH y ESP. RFC 2409 especificaba IKE, donde dos pares se autenticaban, negociaban algoritmos y obtenían material de clave. La independencia de IKE era una virtud: la negociación podía funcionar sin que una autoridad central participara en ese instante.

Esa independencia tenía un precio operativo. Los pares debían verificar certificados o custodiar secretos precompartidos. Diffie–Hellman distribuía el cálculo y podía exponer a un respondedor a presión de denegación de servicio. Los modelos X.509 exigían cadenas de confianza y operaciones de firma. Además, la política del sitio terminaba replicada entre equipos cuya configuración y fiabilidad no siempre eran iguales.

RFC 3129 propuso KINK, Kerberized Internet Negotiation of Keys, para usar la infraestructura de Kerberos. En el modelo de RFC 1510, el cliente se autenticaba ante el KDC, obtenía un ticket de servicio y compartía con ese servicio una clave de sesión transportada de forma protegida. KINK debía convertir esa clave en la base del material usado por las asociaciones IPsec.

El beneficio no consistía simplemente en acortar un saludo. La autenticación inicial, incluso con clave pública mediante PKINIT, podía amortizarse sobre muchos tickets. Los servidores evitaban repetir determinadas operaciones de firma o Diffie–Hellman con cada contraparte. La política se podía gobernar más cerca de la autoridad del reino, y los secretos duraderos dejaban de formar un tejido completo entre pares.

El documento marcó de inmediato el límite: KINK no era un reemplazo de IKE. IKE podía autenticar dos pares e intercambiar claves sin un tercero que estuviera activo. KINK dependía de una autoridad de confianza para obtener las credenciales y los tickets necesarios. La centralización era aceptable sólo cuando ese tercero resultaba viable y deseable.

Las exigencias evitaban que “central” significara “presente en cada operación”. Cualquiera de los dos pares IPsec debía poder iniciar, tanto si actuaba como cliente Kerberos con un TGT como si mantenía un keytab de servicio. El modo user-to-user debía ayudar cuando el respondedor no poseía una clave de servicio convencional. Un par podía pertenecer a varios reinos, y el protocolo debía tratar de forma razonable los desfases absolutos de reloj.

La exigencia más reveladora era el rekey: mientras el ticket de sesión siguiera vigente, los pares debían renovar claves sin pedir ayuda al KDC. El centro emitía confianza limitada en el tiempo; no inspeccionaba cada paquete ni autorizaba cada cambio de clave. Esto contenía parte de la dependencia, pero no la borraba. Cuando las credenciales expiraban o aparecía una relación nueva, el centro volvía a importar.

KINK también debía hacer el trabajo completo de una negociación IPsec. Tenía que crear, modificar, renovar y borrar asociaciones, negociar suites, instalar selectores, trabajar en modo transporte o túnel, admitir AH y ESP, y funcionar con IPv4 e IPv6. El ticket no concedía por sí mismo el derecho a representar una red. La correspondencia entre un principal y un selector seguía en manos de la política local.

Ese punto separa identidad de autoridad. Que el KDC confirme el nombre de una máquina no significa que esa máquina pueda anunciar cualquier prefijo por un túnel. Una mala regla local puede aceptar una identidad genuina para un alcance excesivo. Centralizar la autenticación puede hacer más uniforme el error si los operadores confunden ambos planos.

RFC 3129 tampoco era la especificación final. Tenía categoría Informational y enumeraba requisitos. RFC 4430 llegó en 2006 como Proposed Standard y definió KINK, citando el documento de 2001 como base. La cronología impide contar el deseo como despliegue. Ninguno de los dos RFC demuestra que KINK reemplazara a IKE en producción.

El resto del ecosistema avanzó en paralelo. RFC 4120 actualizó Kerberos V5; RFC 3961 organizó su marco criptográfico; RFC 4556 normalizó PKINIT; RFC 6113 amplió el marco de preautenticación. IKE evolucionó hacia IKEv2 en RFC 4306 y después RFC 7296. La historia de Internet mantuvo varios modelos de confianza porque sus fallos aceptables no eran los mismos.

La fórmula O(n) frente a O(n²) no debe convertirse en marketing. Un KDC reduce relaciones secretas bilaterales en el modelo descrito, pero exige proteger claves maestras, rotar keytabs, sincronizar relojes, diseñar reinos, dimensionar la emisión de tickets y conservar auditoría. Cambia muchas dependencias pequeñas por menos dependencias, mucho más decisivas.

También cambia la forma de una interrupción. Una caída del KDC no implica necesariamente que todo el tráfico IPsec se detenga. Las asociaciones instaladas pueden continuar y un ticket válido puede permitir rekey sin el centro. El daño aparece donde hacen falta credenciales frescas, tickets nuevos o una relación que aún no existía. La ventana depende de la duración de tickets y SA, no de un interruptor binario.

El mismo razonamiento vale para un compromiso. El registro central puede ofrecer una pista sólida de quién obtuvo qué ticket y cuándo. Pero una autoridad capturada puede producir identidades creíbles a escala. La legibilidad y el radio de explosión crecen juntos.

Las consideraciones de seguridad de RFC 3129 fueron prudentes: las asociaciones heredarían la unión de las debilidades de IPsec y Kerberos. La composición no neutralizaba fallos conocidos, y la interfaz entre ambos podía producir otros nuevos.

Por eso el texto merece un lugar en la historia. Antes de que existiera el protocolo terminado, fijó la pregunta institucional. ¿Debe cada extremo cargar con certificados, cálculo, política y secretos, o debe una autoridad común hacer reutilizable parte de esa confianza? KDC no eliminaba la confianza. La concentraba para que una red pudiera administrarla, y obligaba a aceptar las consecuencias de esa concentración.

Fuentes