Resumen
- RFC 9645 define agrupaciones YANG reutilizables para identidad de cliente y servidor, autenticación del par, parámetros Hello y keepalives. Su alcance es una configuración común mínima, no un recibo de cada sesión.
- Configurar un certificado, una clave pública cruda o un PSK demuestra una posibilidad autorizada. No demuestra qué pidió el par, qué identidad se presentó, si hubo reanudación, cómo terminó la validación ni qué sujeto reconoció la aplicación.
- La afirmación “esta conexión autenticó a este actor” requiere enlazar versión de modelo y configuración con la rama real del handshake, el material del par, el resultado de validación, la autenticación opcional del cliente y el resultado de negocio.
Un inventario no es una reconstrucción
La diferencia aparece con claridad durante un incidente. El equipo de plataforma conserva la configuración aprobada. El equipo de PKI confirma que el certificado era válido. El dispositivo muestra que soportaba la versión y la suite requeridas. Sin embargo, nadie puede responder si la conexión fue un handshake completo con certificado, una coincidencia de clave pública cruda, una sesión con PSK externo o una reanudación basada en estado anterior.
RFC 9645 no promete resolver esa investigación. Define ietf-tls-common, ietf-tls-client e ietf-tls-server, además del módulo de enumeraciones de suites mantenido por IANA. Sus agrupaciones se concentran en TLS y dejan dirección, puerto y estrategia de transporte a los modelos que las consumen. El propio RFC llama a su diseño genérico “mínimo común denominador”, no modelo exhaustivo.
Esa modestia delimita responsabilidades. El estándar ofrece un lenguaje compartido para autorizar posibilidades. La pila TLS elige y ejecuta una. La aplicación decide qué significado y qué permisos recibe la identidad resultante. La auditoría falla cuando toma la autoridad del primer nivel y la extiende sobre los otros dos.
Cada rama de identidad sustenta una afirmación distinta
Las cuatro opciones principales de RFC 9645 no son equivalentes. En la rama de certificado intervienen cadena, nombre de referencia, reloj, uso de clave, algoritmos de firma, ancla y política local. La clave pública cruda prescinde de la cadena de certificados y suele depender de una relación exacta con una clave confiable. El PSK de TLS 1.2 mantiene la semántica del protocolo anterior. El PSK externo de TLS 1.3 añade identidad externa, función hash y, opcionalmente, contexto y parámetros de destino.
RFC 9257 advierte que el identificador de un PSK puede observarse y correlacionarse, y que los miembros de un grupo que comparte secreto pueden suplantarse entre sí. RFC 9258 diferencia el PSK importado con contexto, que enlaza mejor el aprovisionamiento externo con la conexión, del PSK sin contexto. Por tanto, “PSK válido” puede acreditar pertenencia a un grupo sin identificar al actor individual.
El recibo debe declarar la rama utilizada, la clase de PSK y la presencia de contexto, junto con una huella o versión protegida del material realmente cargado. No debe guardar el secreto. Reducir todo a “credencial TLS disponible” elimina la atribución que luego se pretende recuperar.
Autenticar al servidor y autenticar al cliente son actos separados
En el cliente, RFC 9645 separa client-identity de server-authentication. La identidad del cliente es opcional porque la autenticación puede residir en una capa superior. Aun configurada, solo se presenta en TLS cuando el servidor la solicita al establecer la sesión.
En el servidor, server-identity y el contenedor opcional client-authentication también son decisiones distintas. Si el segundo no está presente, el servidor no debería pedir credenciales al cliente. Si está presente, CA, certificados finales exactos, claves crudas y mecanismos PSK forman un conjunto aditivo de métodos permitidos.
La etiqueta “mTLS activo” oculta al menos cinco hechos: capacidad de solicitar identidad, solicitud efectiva, presentación del cliente, validación del servidor y creación del principal de aplicación. Después viene un sexto: autorización de la operación. Una sola bandera no puede distinguir una solicitud ausente de una respuesta ausente, una validación fallida o una denegación posterior.
El recibo debe conservar cada transición. Eso permite saber no solo que el canal fue cifrado, sino qué parte asumió cada identidad y dónde terminó la autoridad de TLS.
La reanudación altera la carga probatoria
La especificación vigente de TLS 1.3, RFC 9846, mantiene separados los insumos de versión, algoritmos de firma, grupos, key shares e identidades PSK. El servidor selecciona un PSK compatible y verifica un binder que vincula ese PSK con la transcripción actual.
El binder prueba una relación con este handshake; no demuestra que el certificado original se haya presentado y validado otra vez. Una sesión reanudada puede heredar contexto de una conexión anterior. Un informe que toma el certificado de la configuración estática y lo coloca junto a “TLS exitoso” fabrica continuidad probatoria.
También hay que separar PSK externo de PSK de reanudación. El primero nace fuera de TLS; el segundo procede de una sesión previa. Con early data, la solicitud que importa puede enviarse antes del punto normal de confirmación. Registrar solo el éxito final borra una diferencia relevante de replay y autorización.
Por eso el recibo debe decir si el camino fue completo, reanudado o con datos tempranos, y cuál fue la procedencia del PSK. Lo que no puede hacer es afirmar una nueva validación de certificado cuando el protocolo no la ejecutó.
Versión y suite no son una identidad
hello-params-grouping permite fijar versiones mínima y máxima y una lista ordenada de suites. El estado opcional de algoritmos soportados describe capacidad de implementación. Son controles importantes, pero responden a la criptografía del canal, no a la identidad del par.
El registro TLS de IANA advierte que los algoritmos pierden fortaleza y que la aceptación registral no equivale a recomendación. Las suites de TLS 1.3 tampoco significan lo mismo que las de TLS 1.2. RFC 9325 ofrece guía de despliegue; RFC 9852 exige soporte de TLS 1.3 para nuevos protocolos dentro de su alcance. El nombre puede sobrevivir mientras cambia la decisión local sobre su uso.
La versión y suite negociadas deben figurar en el recibo, pero separadas del modo de identidad, el material presentado y el veredicto. “TLS 1.3 con suite aprobada” no responde si la autenticación se apoyó en certificado, clave cruda, PSK externo o reanudación.
De la autorización de configurar a la prueba de ejecutar
RFC 8342 separa configuración pretendida y estado operacional. RFC 8341 restringe quién puede modificar nodos sensibles. RFC 9641 y RFC 9642 suministran las referencias de truststore y keystore reutilizadas por RFC 9645. Cada capa aporta una pieza; ninguna hereda automáticamente el resultado de la siguiente.
Una referencia de keystore puede resolverse y no ser seleccionada. El truststore puede estar disponible y no recibir certificado. La configuración puede quedar aplicada en un listener que la conexión nunca tocó. TLS puede validar una clave que la aplicación no vincula con una cuenta. La cuenta autorizada todavía puede fallar al ejecutar la operación.
La separación de Heng Lu entre poder simbólico y realidad operativa ordena estos hechos: el modelo controla vocabulario; el cambio aprobado controla intención; la pila ejecuta una rama; la aplicación asigna autoridad y produce un resultado.
El recibo mínimo debería registrar:
- versión RFC/YANG, features, deviations y modelo consumidor;
- revisión aplicada, datastore de origen, aprobador y momento de activación;
- rama de identidad y referencias keystore/truststore efectivamente resueltas;
- huellas o versiones protegidas de credencial y confianza cargadas;
- identificador de sesión y tiempos fiables;
- versión y suite negociadas, separadas del modo de identidad;
- ruta completa, reanudada o early data, y procedencia/contexto del PSK;
- identidad presentada, método y resultado de validación, más incertidumbres;
- solicitud, respuesta, validación y principal en la autenticación del cliente;
- final del handshake, alertas, reintentos o fallback;
- autorización, operación, condición de aceptación y resultado aplicativo;
- campos desconocidos y responsable de aprobar la afirmación final.
Ninguna fuente citada impone este formato. Es un diseño operativo derivado de sus fronteras. Permite una frase limitada y comprobable: para esta sesión y operación, bajo esta configuración aplicada, se ejecutó esta rama, se validó esta identidad, se creó este principal y se obtuvo este resultado.
Fuentes
- Especificación inicial mínima
- Capas de realidad y poder simbólico
- Primacía del código en ejecución
- Historial de RFC 9645
- Página informativa de RFC 9645
- RFC 9645 en HTML
- RFC 9645 en texto
- RFC 9645 en XML
- Erratas integradas de RFC 9645
- Parámetros TLS de IANA
- Módulo YANG IANA de suites TLS
- RFC 9641: modelo de truststore
- RFC 9642: modelo de keystore
- RFC 9846: TLS 1.3 vigente
- RFC 9852: TLS 1.3 para protocolos nuevos
- RFC 9325: despliegue seguro de TLS
- RFC 9257: guía sobre PSK externos
- RFC 9258: importación de PSK externos
- RFC 8341: control de acceso a configuración
- RFC 8342: arquitectura de datastores de red
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance