Resumen

  • Si el KDC rechaza los parámetros ECDH, RFC 5349 permite devolver TD-DH-PARAMETERS en orden de preferencia junto con KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. El cliente puede reintentar, pero el error que transporta la lista no está protegido por integridad.
  • La lista solo debe reducir un conjunto permitido de antemano por la política local. Un reintento correcto acredita que se ejecutó una opción aceptable; no acredita que el orden recibido fuera auténtico ni que el KDC lo hubiera enviado así.
  • Una cadena X.509 válida y una firma CMS correcta no sustituyen la comprobación del punto público sobre la curva adecuada. Si se reutiliza una clave privada ECDH duradera, los puntos inválidos repetidos pueden revelar la clave poco a poco.

Influencia no es autoridad

Un sistema puede actuar a partir de información sin concederle el derecho final de decisión. Eso es exactamente lo que exige este intercambio. La respuesta del KDC aporta candidatos y prioridad. La política del cliente decide cuáles pueden cruzar la frontera.

La diferencia importa porque el mensaje es accionable. Cambia el segundo intento, altera la curva elegida y puede terminar en una autenticación válida. Si el registro solo conserva el resultado, la influencia queda disfrazada de autoridad.

El diseño correcto trata la lista como una entrada que debe intersectarse con reglas locales. No la trata como una actualización remota de esas reglas. Si no hay intersección, el fracaso no es un problema que deba resolver un modo compatible; es la aplicación de la política.

También el KDC debe distinguir entre una curva que la biblioteca sabe procesar y una curva que la organización permite. La capacidad técnica no crea permiso.

El atacante no necesita provocar un fallo

Es tentador buscar el ataque en una autenticación rota. Sin embargo, un intermediario puede eliminar de la lista la opción mutuamente preferida y dejar otra que siga autorizada por el cliente. El segundo intento funciona.

La sesión resultante puede ser criptográficamente correcta. La política local puede haber evitado una degradación por debajo de su umbral. Aun así, la selección ya no demuestra la preferencia real del KDC.

El éxito, por tanto, no limpia el pasado. Prueba una intersección segura en el mejor de los casos, no la autenticidad de la señal que condujo a ella.

La pregunta de auditoría debe dividirse: ¿se usó una opción permitida y bien validada? ¿La secuencia de preferencias provenía realmente del KDC? Una respuesta afirmativa a la primera no resuelve la segunda.

Conservar el orden, no solo los nombres

TD-DH-PARAMETERS está ordenado según la preferencia del KDC. Guardar las curvas como conjunto destruye esa semántica. La misma lista con otro orden puede producir otro resultado.

El recibo mínimo contiene la propuesta original del cliente, el código de rechazo, la lista exacta recibida, la versión de la política local, la intersección, el algoritmo de selección, el valor reintentado y el resultado. Si la negociación estaba deshabilitada, esa decisión también debe quedar registrada.

Conviene conservar por separado la entrada bruta y la lista filtrada. De otro modo, el sistema solo mostrará aquello que sobrevivió a sus propios controles y no podrá explicar qué intentó influirlos.

Una huella de la configuración de política evita reinterpretar un hecho histórico con reglas modificadas meses después.

El certificado y el punto responden a preguntas distintas

RFC 5349 incorpora ECC a PKINIT mediante certificados, firmas y estructuras CMS ya conocidas. La validación X.509 puede demostrar que una cadena llega a una raíz aceptada, que las restricciones se cumplen y que las firmas verifican.

Todavía falta comprobar el objeto matemático que alcanzará ECDH. El punto público debe pertenecer a la curva correcta y satisfacer las condiciones exigidas antes de combinarse con la clave privada.

Un contenedor autenticado no convierte automáticamente todo bit interior en una entrada segura. La validez del certificado y la validez del punto son recibos independientes.

Agruparlos bajo una marca «certificado válido» borra el control que más importa frente a entradas de curva mal formadas. Los registros deben mostrar análisis, ruta de certificación, firma, política de algoritmo y validación del punto como pasos separados.

La reutilización convierte una omisión en proceso

RFC 5349 advierte de un riesgo concreto: si el receptor usa una clave privada ECDH a largo plazo y acepta un punto que no es válido en la curva correcta, el cálculo puede filtrar información sobre esa clave. La repetición puede terminar exponiéndola por completo.

Esto cambia la unidad de análisis. No basta con revisar una transacción. Hay que contar cuántas entradas adversas han tocado la misma clave, durante cuánto tiempo y qué observaciones devolvió el sistema.

Una limitación de frecuencia reduce oportunidades, pero no repara la validación. Rotar la clave reduce la acumulación, pero tampoco autoriza puntos inválidos. El control primario sigue siendo rechazar antes del cálculo.

Cada intento debería vincular origen, identificador de curva, resultado de validación, identidad y antigüedad de la clave, motivo de rechazo, latencia observable y contador de reutilización.

Los nonces limitan la licencia para reutilizar

RFC 4556 usa clientDHNonce y serverDHNonce para que las partes permitan la reutilización de claves; RFC 5349 conserva ese marco para ECDH. La existencia del mecanismo no es una autorización ilimitada.

Los nonces forman parte de la evidencia de que la reutilización estuvo consentida en ese contexto. Si solo se conserva la clave derivada o el ticket, se pierde la condición de autoridad que permitía mantener el par ECDH.

La ventaja operativa —menos cálculo y quizá menos latencia— debe compararse con la ampliación de exposición: más solicitudes comparten el mismo secreto privado y cualquier fallo de validación se vuelve repetible.

La trazabilidad debe unir nonces, política, par de claves, periodo de uso, número de operaciones, controles de punto y destrucción. Ninguno se deduce de la frase «intercambio completado».

Menos bits no significan menos gobierno

RFC 5349 explica el atractivo de ECC mediante claves más pequeñas para una seguridad comparable a RSA o DSA según las referencias de la época. El cuadro de equivalencias sirve para entender el razonamiento histórico del diseño.

No cuantifica certificados, módulos de hardware, pruebas, resistencia a canales laterales, calidad de bibliotecas, despliegue de nuevas políticas ni velocidad de sustitución. El coste operativo no cabe en la longitud de una clave.

Una codificación menor puede ahorrar ancho de banda o almacenamiento y, al mismo tiempo, añadir identificadores, parsers, curvas y ramas de negociación. Solo las mediciones del sistema desplegado pueden cerrar la comparación.

Tampoco debe usarse una tabla de 2008 como catálogo de compras contemporáneo. Las decisiones actuales necesitan normas y evaluaciones actuales.

Soporte obligatorio no es evidencia de ejecución

P-256 y P-384 son requisitos de soporte para las implementaciones conformes a RFC 5349. Constituyen un suelo de interoperabilidad.

No demuestran que una instalación las habilite, que el cliente las proponga, que la política las permita, que el KDC las devuelva, que el reintento las seleccione o que el cálculo llegue a ejecutarse. Lo mismo vale para el requisito histórico de ecdsa-with-Sha256.

Los inventarios deben separar al menos: implementado, configurado, ofrecido, recibido, permitido, seleccionado, validado y ejecutado. Cada transición exige su propia evidencia.

Confundir soporte con uso crea una falsa visibilidad: la organización cree conocer su superficie criptográfica cuando solo ha leído la documentación del producto.

Normalización y riesgo compartido

Las curvas nombradas permiten identificar parámetros con un objeto común, reducen tamaño y simplifican la interoperabilidad. Los parámetros explícitos ofrecen flexibilidad, pero añaden variación y validación.

Una curva muy extendida concentra claves y dependencias. Si aparece una debilidad en la curva o en su ruta de implementación, el alcance puede ser sistémico. La concentración merece inventario y plan de reemplazo.

La diversidad tampoco es una garantía: más curvas significan más código, más combinaciones, más negociación y más probabilidad de configuraciones divergentes. Hay que equilibrar concentración frente a complejidad real.

Las métricas útiles son número de claves, bibliotecas, plataformas, validación efectiva, dependencia de hardware, tiempo de rotación y frecuencia observada de cada selección.

El certificado puede mover la fuente de parámetros

Cuando un certificado ECC aporta los parámetros, ya no hace falta preconfigurarlos por separado. El cambio reduce una tarea operativa, pero desplaza la custodia hacia la emisión del certificado y su validación.

El parámetro no se vuelve legítimo por estar dentro del certificado. Deben converger la confianza en el emisor, las restricciones de uso, la política de algoritmo, la curva y el contexto PKINIT.

Registrar la procedencia evita que un diseño con menos ficheros parezca un diseño sin autoridad. La fuente puede ser configuración local, certificado, lista del KDC u otro mecanismo; cada una tiene controles distintos.

La pregunta no es «¿hay menos configuración?», sino «¿quién puede cambiar ahora el parámetro y qué recibo deja?».

Seis fronteras después del primer paquete

Tras aceptar el punto, las partes calculan el punto ECDH y convierten su coordenada x en el octeto DHSharedSecret que alimenta RFC 4556. Eso acredita la producción de material criptográfico para la siguiente fase.

No acredita por sí solo la identidad institucional completa, la emisión del ticket, un ticket de servicio, la autorización de la aplicación o el resultado de la acción. Cada frontera conserva derecho de rechazo.

El documento es Informational, publicado en septiembre de 2008, y afirma no cambiar la sintaxis ni la semántica de RFC 4556. La consulta capturada de erratas no mostraba registros para RFC 5349; esa ausencia documental no garantiza todas las implementaciones.

La lectura duradera es sobre autoridad: una entrada no autenticada puede orientar, una política local puede permitir, una validación matemática puede proteger la clave, Kerberos puede autenticar y la aplicación todavía debe decidir.