Resumen

  • Un Exported Authenticator combina Certificate, CertificateVerify y Finished con claves derivadas de una conexión TLS o DTLS establecida. Prueba posesión de otra identidad X.509 en esa conexión, sin cambiar el estado TLS.
  • No incluye hora de creación ni número de stream. El contexto único limita repetición y confusión dentro de la conexión; la aplicación debe asociar por separado la operación, el momento efectivo y el permiso.
  • El registro operativo debe separar solicitud, vínculo de conexión, validación criptográfica, política de certificado, rechazo vacío autenticado y decisión de autoridad. Un terminador TLS rompe el vínculo aunque ambos lados muestren el mismo certificado.

El verificador acertó y el autorizador se equivocó

La conexión se abrió a las 13:58 con la identidad del handshake normal. Varias solicitudes avanzaron en paralelo. Cinco minutos después llegó la respuesta a una petición de identidad adicional y las comprobaciones de RFC 9261 terminaron con éxito.

El error fue convertir ese resultado en una propiedad retroactiva. RFC 9261 dice que los autenticadores son independientes y unidireccionales; crearlos o validarlos no produce un cambio explícito en TLS. La aplicación recibe una evidencia, no una nueva historia.

Puede decidir que, tras una barrera verificable, la identidad habilite una operación futura. No puede atribuirle solicitudes anteriores, elegir por sí sola un stream ni fabricar una fecha ausente. TLS aporta el vínculo con la conexión; la aplicación conserva la autoridad semántica.

Una prueba ligada a secretos de una sola conexión

El mecanismo reutiliza formatos de TLS 1.3 sin iniciar otro handshake. Certificate presenta la cadena X.509; CertificateVerify demuestra la clave privada; Finished protege la transcripción con una clave derivada del estado de la conexión. Los mensajes se serializan sin records TLS y viajan por la capa de aplicación, en la conexión existente o en otro canal de protección equivalente.

Cliente y servidor usan etiquetas distintas. En TLS 1.3 se emplea exporter_master_secret, nunca el secreto temprano. En TLS 1.2 hacen falta una suite con PRF y Extended Master Secret. Así se evita que una firma con el certificado pueda separarse de la sesión que le dio contexto.

La afirmación obtenida es estrecha: este extremo, dentro de esta conexión, poseía la clave de una identidad aceptada para esta transcripción. No demuestra que la identidad estuviera activa desde el comienzo, que sea válida en otra conexión o que controle todos los objetos multiplexados.

La política de cadena es otra comprobación. Signature y Finished correctos no arreglan caducidad, emisor no permitido, nombre incorrecto ni ausencia de permiso empresarial. Conviene conservar tres estados: estructura criptográfica, confianza X.509 y decisión de autorización.

El contexto de solicitud tiene alcance local

certificate_request_context identifica la petición y debe ser único dentro de la conexión para las formas de solicitud de RFC 9261. También debería ser impredecible. El autenticador lo devuelve, de modo que una prueba aceptada no pueda satisfacer otra solicitud de la misma conexión.

No es un identificador mundial ni un reloj. Cuando gateway, servicio de identidad y worker generan contextos con inventarios separados, pueden colisionar aunque cada base local parezca limpia. La propiedad exigida por el wire es común a toda la conexión; también debe serlo su dueño de software.

Un contador visible puede ser único y predecible. Un generador aleatorio puede repetir tras restaurar una instantánea. El registro debería conservar hash del contexto, época del generador, conexión, extensiones, objetivo y hora local, nunca secretos exportados ni claves privadas.

El cliente necesita una solicitud previa; el servidor puede presentar una prueba espontánea. Esa asimetría es parte de la evidencia. Un autenticador cliente sin contexto pendiente se rechaza; uno servidor espontáneo no demuestra que el cliente lo pidiera.

La conexión no nombra el stream

HTTP/2 multiplexa muchos streams. QUIC prohíbe la autenticación cliente post-handshake de TLS porque el CertificateRequest no se correlaciona de forma fiable con el evento aplicativo que lo originó.

RFC 9261 permite que solicitud y prueba circulen en la aplicación, pero no inventa la correlación. El protocolo superior debe declarar que el contexto X afecta al stream 41, a la operación Y y sólo después de Z.

La opción segura es prospectiva y mínima. Trabajo ya ejecutado, colas anteriores y streams hermanos conservan su identidad. Elevar toda la conexión puede ser una decisión válida en un protocolo dedicado, pero exige reglas de orden, barrera, alcance y rollback observables.

Tampoco hay timestamp criptográfico de creación. Recepción, validación y efecto son tres tiempos. Un solo campo authenticated_at impide distinguir retraso, replay y reordenamiento.

Un proxy TLS es una frontera, no un detalle

El Handshake Context se deriva de la conexión inicial. Un autenticador creado en A y validado contra B falla. Un proxy que termina TLS crea dos conexiones aunque reenvíe nombres o use la misma cadena.

Aceptar por igualdad de certificado destruiría el vínculo de RFC 9261. Si la identidad debe cruzar el terminador, hace falta una delegación explícita con emisor, audiencia, caducidad y custodia, o dos pruebas independientes cuyo enlace sea otra decisión de confianza.

Reconexión y failover producen la misma ruptura. El privilegio antiguo no debería sobrevivir por semejanza de sesión. Se solicita otra prueba, se reduce el rol o se usa un mecanismo de continuidad diseñado expresamente.

Rechazar también puede autenticarse

Si el extremo no tiene una identidad adecuada o no desea entregarla, puede enviar un empty authenticator. Conserva Finished y omite Certificate y CertificateVerify. El MAC autentica la negativa, pero no ofrece una identidad válida.

Debe registrarse como rechazo vacío autenticado, distinto de silencio, corrupción, firma falsa o cadena rechazada. Una operación de bajo riesgo puede continuar; otra puede detenerse. Repetir sin límite convierte una negativa legítima en bucle de denegación de servicio.

Cuatro registros para una sola decisión

El registro de conexión incluye versión, suite, finalización, Finished del peer, EMS y un identificador no secreto. El de solicitud incluye rol, hash y unicidad del contexto, extensiones, objetivo, tiempo y canal.

El de validación guarda modo solicitado o espontáneo, hash de Certificate, fingerprints, algoritmo y resultado de CertificateVerify, Finished, coincidencia de conexión, política X.509, rechazo vacío y tiempos. El de autoridad fija decisor, stream u operación, privilegio anterior y nuevo, efecto, caducidad y rollback.

Un porcentaje de éxito no basta. Puede subir mientras se repiten contextos o se expande el permiso. Un rechazo por conexión errónea puede ser la señal correcta de que el terminador no fue atravesado.

IANA registra las etiquetas; OpenSSL y BoringSSL muestran el sustrato exporter. Eso no prueba adopción de RFC 9261 ni una política correcta. Sólo la ejecución reconstruible convierte la especificación en evidencia.

Fuentes