Resumen

  • RFC 5349 incorpora certificados y firmas ECC y acuerdo ECDH a PKINIT sin cambiar la sintaxis ni la semántica de los mensajes de RFC 4556. El cliente ofrece parámetros; si el KDC los rechaza, puede devolver una lista ordenada y el cliente puede reintentar.
  • Los errores Kerberos no están protegidos por integridad. La lista TD-DH-PARAMETERS puede ser alterada hacia parámetros más débiles o que no eran la preferencia mutua. El reintento válido es el que también satisface la política local versionada del cliente y del KDC.
  • El éxito criptográfico no comprime toda la cadena: hay que probar curva, punto público, certificado, frescura, derivación, identidad del KDC, ticket, autorización del servicio y resultado de la sesión por separado.

El éxito del segundo intento ocultaba la decisión decisiva

Un sistema de operaciones suele registrar el último estado. Primer intento fallido; segundo intento exitoso; autenticación completa. Esa secuencia no muestra por qué el segundo intento estaba permitido.

El cliente ECDH codifica su valor público y los parámetros de dominio en clientPublicValue. El KDC puede responder con KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED y una lista en orden de preferencia. El cliente escoge y vuelve a enviar.

Pero la lista viaja dentro de un error sin integridad. Un atacante puede eliminar opciones, alterar el orden o mantener solo una alternativa menos deseable. Si el cliente interpreta “apareció en la lista” como “queda aprobada”, la red ha conseguido modificar política sin credenciales administrativas.

El control real ocurre antes del segundo envío. El cliente compara la opción con su conjunto local. El KDC hace lo propio al recibirla. La lista ayuda a evitar combinaciones inútiles; no concede una excepción. Registrar solo el parámetro final borra ese control.

Una allow-list aprendida del tráfico no es una allow-list

El peligro no termina en una sesión. Un agente de compatibilidad puede memorizar la curva que funcionó y usarla en conexiones futuras. La caché reduce latencia, pero también vuelve permanente una observación que quizá nació de un mensaje manipulado.

La persistencia debe distinguir tres clases: soporte observado, permiso local y excepción temporal. El soporte observado dice que un intercambio llegó más lejos. El permiso identifica una decisión de un responsable. La excepción define alcance, fecha de expiración y propietario.

Si esas clases comparten una columna, el sistema convierte telemetría en gobierno. Una curva puede entrar por compatibilidad, sobrevivir al retiro oficial y aparecer después como “configuración existente” que nadie se atreve a eliminar.

La evidencia mínima incluye digest de la lista recibida, origen aparente, política y versión, regla que coincidió, identidad del workload y duración de la excepción. El reintento exitoso debe apuntar a esa evidencia, no reemplazarla.

Curva aceptada y punto válido no son el mismo control

RFC 5349 dedica una advertencia especial a la validación de la clave pública. El receptor debe comprobar que el punto recibido es válido y pertenece a la curva correcta. Cuando usa una clave privada ECDH duradera, omitir ese control permite ataques iterativos que revelan información hasta comprometerla.

La selección de P-256 o P-384 no ejecuta la comprobación por sí sola. El identificador describe los parámetros esperados; los bytes del punto siguen siendo una entrada hostil. El registro debe conservar ambos resultados.

Esto cambia la respuesta a incidentes. Un fallo único contra una clave efímera tiene un alcance distinto de cien puntos inválidos procesados con la misma clave larga. Sin un identificador de instancia de clave y el estado de reutilización, el operador no puede calcular qué debe rotar.

SP 800-56A Rev. 3 de NIST ofrece el contexto actual capturado para establecimiento de claves y validación. SP 800-186 y FIPS 186-5 completan el panorama actual de parámetros y firmas. El anuncio de actualización de 2026 es un cambio a vigilar, no evidencia de que la revisión capturada haya sido retirada.

El certificado ahorra distribución y conserva obligaciones

RFC 5349 observa que los parámetros incluidos en certificados ECC pueden evitar una preconfiguración separada. En una flota grande, eliminar otro archivo de parámetros reduce divergencias.

No elimina la decisión. La cadena del certificado, el uso de clave, la vigencia, la identidad y la política local siguen siendo controles independientes. También sigue siendo necesario validar el punto de la sesión.

Esta diferencia importa al automatizar. “Tomar la curva del certificado” puede significar “obtener la propuesta de un objeto autenticado”. No significa “saltar todas las reglas de aceptación”. Un certificado válido para una finalidad no convierte su curva en opción autorizada para toda finalidad.

Derivar el secreto no emitió el ticket

Tras aceptar parámetros, el KDC devuelve su valor público. Las partes calculan el punto ECDH y convierten su coordenada x en el secreto utilizado por PKINIT.

Ese estado prueba compatibilidad matemática con las entradas. Aún quedan la respuesta autenticada, la validación de identidad, la emisión del ticket inicial, el ticket del servicio y la autorización final. La aplicación puede negar acceso aunque ECDH haya sido correcto; también puede aceptar al principal equivocado por un fallo en otra capa.

Por eso la métrica debe separar parameter_accepted, point_valid, shared_secret_derived, kdc_reply_verified, ticket_issued, service_authorized y session_established. Un único campo pkinit_success sirve para disponibilidad, no para atribución.

La base común también es un punto común de fallo

RFC 5349 exige soporte de P-256 y P-384 y discute el equilibrio entre curvas comunes, eficiencia, estructura algebraica y concentración. No documenta una ruptura de esas curvas. Expone el tipo de decisión.

Una base estrecha simplifica interop y pruebas. También concentra el parque en menos implementaciones y parámetros. La diversidad puede reducir el fallo común, pero multiplica rutas de código y errores de validación. La respuesta es un inventario explícito y una política de retiro, no adoptar diversidad o uniformidad por reflejo.

RFC 8636 muestra que el problema continúa en la agilidad de algoritmos PKINIT. La ausencia de un KDF esperado puede significar peer antiguo o downgrade; la política local decide si se continúa. El borrador postcuántico de 2026 vuelve a usar hints y reintentos, pero sigue siendo trabajo en curso y no prueba un despliegue.

El documento no es un censo de Kerberos actual

RFC 5349 es Informational. IANA registra códigos y tipos, no cuántos KDC implementan cada función. Las fuentes no ofrecen tasas de adopción, fallos reales ni prevalencia de reutilización.

La Minimum Initial Specification de Lu Heng funciona como analogía posterior: el protocolo común define un vocabulario mínimo y la decisión futura permanece en el participante. Reality Layers ayuda a no mezclar identificador, recomendación, validación, ticket y experiencia del usuario. Ninguna nota es fuente histórica del RFC.