Prompt y alcance
Un servicio empresarial desea que los clientes con claves autorizadas accedan a recursos seleccionados sin permitir que los clientes no autenticados sondeen su existencia a través de respuestas o desafíos 401. El equipo está considerando el IETF RFC 9729, un RFC de Standards Track de febrero de 2025. El esquema utiliza un exportador de material de claves TLS para crear una entrada de firma vinculada a la conexión y envía la prueba en Authorization: Concealed.
Diseña el despliegue del cliente, el gateway perimetral (edge) y el origen. Explica la salida del exportador de 48 bytes, los parámetros de autenticación, el requisito de versión de TLS, la reutilización de conexiones, la revocación de claves, el fallback heredado y las pruebas de lanzamiento (rollout). Incluye la errata verificada de 2026 en la auditoría de implementación.
Qué evalúa el entrevistador
El entrevistador quiere que separes la capacidad de ocultar la autenticación de la garantía de frescura: RFC 9729 no envía ningún desafío, pero la frescura de la prueba está delimitada por la vida útil de la conexión TLS subyacente.
Una respuesta sólida cubre el reenvío seguro de Concealed-Auth-Export, claves específicas de protocolo, aislamiento de multiplexación en HTTP/2 y HTTP/3, consistencia de la caché de revocación, comportamiento de fallback y diagnóstico de errores de configuración en lugar de simplemente nombrar unos pocos encabezados.
Aclaraciones para hacer primero
- ¿Quién emite las claves del cliente, son las claves específicas del origen y se admiten claves de corta duración?
- ¿Están separados el gateway y el origen, y cómo se pasa la salida del exportador TLS entre ellos?
- ¿Requiere el recurso frescura a nivel de conexión o a nivel de solicitud?
- Si un cliente heredado solo admite TLS 1.2, ¿se negoció Extended Master Secret?
- ¿Debe la revocación surtir efecto en cuestión de segundos o es aceptable una ventana de caché?
Una respuesta de 30 segundos
“Mantendría un directorio de claves públicas por origen. El cliente utiliza el exportador RFC 9729 en una conexión TLS, firma el contexto prescrito y envía los parámetros; el gateway solo analiza y reenvía el material confiable del exportador, mientras que el origen toma la decisión final de autenticación y autorización. TLS 1.3 satisface el requisito de vinculación; TLS 1.2 necesita Extended Master Secret o la solicitud se considerará no autenticada. Utilizaría una rotación de claves de doble lectura y escritura única, junto con cachés de revocación cortas. Debido a que la prueba tiene un alcance de conexión, una frescura más estricta requiere el reemplazo de la conexión. Las métricas de lanzamiento cubren el análisis sintáctico, la verificación, la revocación y el fallback sin revelar la existencia del recurso.”
Solución paso a paso
Construir el directorio de claves y orígenes
Para cada origen, mapea los ID de clave con claves públicas, algoritmos, realms, horas de emisión y estado de revocación. La clave privada de un cliente se dedica exclusivamente a la autenticación Concealed y no se reutiliza en otro protocolo. RFC 9729 añade un prefijo de firma fijo, pero el despliegue sigue siendo responsable de la separación de claves. Los ID de clave no deben codificar la privacidad del usuario; los registros de auditoría utilizan identificadores irreversibles internos.
Calcular la prueba vinculada a la conexión
El cliente utiliza la etiqueta de exportador EXPORTER-HTTP-Concealed-Authentication, el contexto especificado y una salida de 48 bytes. Los primeros 32 bytes alimentan la entrada de la firma y los últimos 16 bytes se envían como material de verificación. El contexto incluye algoritmo, ID de clave, clave pública, esquema, host, puerto y realm. Una discrepancia es un fallo de verificación; un analizador permisivo no debe “repararla”.
exported = TLS-Exporter(label, context, 48)
signature_input = exported[0:32] + domain_separation_prefix
verification = exported[32:48]
Authorization: Concealed k=..., a=..., s=..., p=..., v=...Definir el límite gateway-origen
Un origen monolítico puede leer el exportador TLS directamente. Cuando está dividido, el gateway valida la sintaxis de los parámetros y envía la salida del exportador de 48 bytes en Concealed-Auth-Export a través de un canal interno confiable. Un cliente público puede falsificar un encabezado con ese nombre, por lo que el gateway debe sobrescribir o eliminar el valor externo. El origen sigue comprobando los campos de destino, algoritmo, ID de clave, clave pública y firma; el análisis del gateway no constituye autorización.
Aplicar las restricciones de TLS y protocolo
RFC 9729 requiere TLS 1.3, o TLS 1.2 con Extended Master Secret. De lo contrario, el servidor trata la solicitud como no autenticada. HTTP/2 y HTTP/3 pueden usar la vinculación, pero la prueba a nivel de conexión puede cubrir varias solicitudes en una sola conexión. Los clientes y gateways deben aislar los contextos de seguridad para que un inquilino no pueda leer los encabezados Authorization de otro inquilino.
Manejar la frescura, reutilización y reproducción (replay)
La frescura del exportador dura solo lo que dure la conexión TLS; no es un nonce independiente por solicitud HTTP. Si un recurso necesita una ventana más corta, exige una nueva conexión, por ejemplo cerrándola o enviando HTTP/3 GOAWAY, y combina eso con ID de clave de corta duración y la política de tiempo del servidor. Nunca trates v como un nonce de solicitud ni aceptes una firma sin verificar host, puerto y realm.
Rotar, revocar y aplicar fallback
Utiliza una rotación de doble lectura y escritura única: publica la nueva clave, acepta temporalmente el ID de clave antiguo, migra a los clientes y luego revoca la clave antigua. La revocación se verifica antes de la autorización y el TTL de la caché junto con la invalidación son explícitos. Un cliente heredado puede usar la ruta de autenticación existente, pero las respuestas de fallback mantienen la misma forma externa para no divulgar si existe un recurso.
Observar y diagnosticar fallos
Segmenta los fallos de análisis de parámetros, TLS no admitido, ID de clave desconocidos, discrepancia de clave pública, fallo de firma, aciertos de revocación, errores de reenvío de gateway y tasa de fallback por origen, versión de cliente, protocolo y algoritmo. Nunca registres claves privadas, firmas completas o claves de usuario vinculables. Audita la errata verificada que afecta a la cadena de contexto de la Sección 3.3 de RFC 9729 y al ABNF de enteros de la Sección 4.
Realizar pruebas y despliegue por etapas de forma segura
Habilita primero un origen y un recurso revocable de bajo privilegio. Prueba TLS 1.3, TLS 1.2 más EMS, HTTP/2, HTTP/3, gateways divididos y reemplazo de conexión. Inyecta host, puerto, realm, algoritmo, ID de clave, longitud de exportador incorrectos, encabezados duplicados, caché de revocación obsoleta y casos de conexiones entre diferentes inquilinos; cada uno debe tratarse como no autenticado. El rollback detiene la emisión de nuevas claves y la aceptación del esquema, manteniendo al mismo tiempo el directorio antiguo y el registro de auditoría.
Respuesta modelo de alta calidad
“RFC 9729 es una autenticación vinculada a la conexión y no sondeable, no un nonce por solicitud. El cliente construye el contexto del exportador, obtiene 48 bytes y firma con una clave dedicada. El gateway valida la sintaxis y reenvía la salida confiable del exportador; el origen verifica las condiciones de TLS, los campos de destino, el ID de clave, la clave pública, la firma, la revocación y la autorización. Se requiere TLS 1.3 o TLS 1.2 más EMS. Las claves están delimitadas al origen y se rotan con lecturas dobles. Una mayor frescura implica reemplazar la conexión. Las métricas de lanzamiento cubren el análisis, la verificación, la revocación y el fallback, y el rollback detiene el uso del nuevo esquema sin exponer el estado del recurso.”
Errores comunes
- Tratar el exportador como un nonce por solicitud → una prueba puede reutilizarse en una conexión larga → declarar la frescura de la conexión y reemplazar conexiones cuando sea necesario.
- Verificar únicamente en el gateway → el origen puede confiar en un encabezado interno falsificado → el origen verifica el contexto y la autorización.
- Aceptar TLS 1.2 sin EMS → la vinculación del exportador es insuficiente → tratarlo como no autenticado.
- Reutilizar claves entre protocolos → confusión de firmas entre protocolos → dedicar claves al esquema y al origen.
- Almacenar en caché la revocación durante demasiado tiempo → un cliente revocado conserva el acceso → definir TTL, invalidación y precedencia.
- Devolver diferentes errores de recursos en fallback → la existencia del recurso se vuelve observable → mantener el estado externo uniforme y registrar la razón internamente.
Preguntas y respuestas de seguimiento
Pregunta de seguimiento 1: ¿Por qué el origen no envía un desafío?
Un desafío le indica a un cliente no autenticado que el recurso espera autenticación, frustrando el objetivo de no sondeabilidad. RFC 9729 permite que el cliente envíe una prueba derivada del material del exportador TLS vinculado a la conexión.
Pregunta de seguimiento 2: ¿Por qué dividir 48 bytes en 32 y 16?
La especificación firma los primeros 32 bytes y envía los últimos 16 como material de verificación para que el servidor pueda confirmar la salida del exportador. Las implementaciones deben usar esos rangos exactos, no tratar la totalidad de los 48 bytes como un nonce.
Pregunta de seguimiento 3: ¿Es seguro reenviar el exportador desde el gateway?
Solo en un canal confiable y con integridad protegida entre gateway y origen. Un cliente público puede falsificar el nombre del encabezado, por lo que el gateway debe sobrescribirlo o eliminarlo, y el origen debe autenticar el canal interno y validar la longitud.
Pregunta de seguimiento 4: ¿Cómo se maneja la revocación en una conexión existente?
Verifica la revocación en cada decisión de autorización, no solo cuando se crea la conexión. Para una frescura más estricta, revoca la clave antigua, señala el cierre de la conexión y exige que el cliente se vuelva a conectar con una nueva clave.