Resumen

  • La RFC 9729 permite que un cliente aprovisionado firme material derivado de la sesión TLS y presente la credencial en la primera petición, sin esperar un reto que revele el servicio.
  • La ocultación depende de la distribución externa de claves, el terminador TLS correcto, la transmisión fiable de Concealed-Auth-Export, la vida de la conexión, la separación entre contextos y una revocación demostrable.
  • Tratar todos los fallos como ausencia protege la superficie pública; agruparlos también en el plano interno impide detectar claves antiguas, rutas equivocadas y fallos de autorización.

Pensemos en dos peticiones idénticas. Una apunta a una ruta inventada. La otra apunta a una capacidad real, pero llega sin la credencial adecuada. Para un observador no autorizado, la RFC 9729 exige que no haya una diferencia aprovechable. Para el operador, confundir ambas peticiones sería una derrota.

Concealed cambia de dónde sale la frescura. En vez de obligar al servidor a enviar un nonce mediante un reto 401, el cliente usa un exportador de material de clave TLS. Puede preparar la prueba en su primera petición. El servidor evita confirmar que espera autenticación. Pero la relación de confianza debe existir antes de ese momento.

Antes del protocolo hay una decisión de pertenencia

El cliente dispone de identificador de clave y par asimétrico. El origen conserva una tabla de identificadores autorizados y claves públicas. La norma deja fuera el mecanismo de distribución. También deja fuera quién decide el acceso, cómo se protege el secreto, cuánto dura y cómo se retira.

Por eso la primera evidencia no es la firma, sino el estado de la relación: emisor, población autorizada, origen, realm, huella pública, activación, caducidad, revocación y generación de tabla. Una baja en recursos humanos no cambia por sí sola todos los verificadores. Borrar una fila no demuestra que cada región haya cargado la nueva versión.

La revocación termina cuando una prueba controlada falla en todos los caminos que podrían servir el recurso. Si se necesita invalidar pruebas ligadas a conexiones antiguas, hay que drenar esas conexiones de forma explícita.

El contexto TLS delimita la prueba

La etiqueta registrada es EXPORTER-HTTP-Concealed-Authentication. El contexto incluye algoritmo, ID y clave pública, más esquema, host, puerto y realm. El resultado tiene 48 bytes: 32 alimentan la firma y 16 aparecen como verificación v. La credencial añade k, a, p y s.

El servidor compara la clave presentada con la almacenada, los bytes de verificación con el exporter y la firma con la clave aceptada. Así evita convertir un lookup de ID en autenticación y reduce la confusión de claves.

La prueba está unida a la conexión y al origen descrito, no a cada método, ruta o cuerpo. Varias peticiones con la misma clave en la misma conexión generan la misma prueba. Un contexto multiplexado que pueda leer el Authorization de otro puede repetirlo. La política de aislamiento de cabeceras forma parte del perímetro.

La conexión también marca la edad de la frescura. Una sesión persistente puede mantener la misma base criptográfica mientras cambia la política humana. Forzar una conexión nueva mejora la actualidad, pero consume capacidad y añade puntos de fallo. Conviene registrar edad, reanudación, versión TLS y motivo de renovación.

Cuando el proxy termina TLS, afirma un hecho de autenticación

El frontend conoce la sesión con el cliente; el backend conoce la base de claves. Si son servidores distintos, el frontend envía la cabecera original y agrega Concealed-Auth-Export con los 48 bytes. El backend no puede derivarlos de su propio enlace al proxy.

La confianza es explícita: el backend ignora ese campo si no confía ya en quien lo envía; el frontend no debe dejar pasar una copia aportada por el cliente. Una simple lista de direcciones puede ser insuficiente en redes compartidas. La identidad del proxy, la configuración del host, el identificador de conexión y la ruta al backend deben quedar unidos.

Un cambio de ingress puede normalizar el host de forma distinta. Un service mesh puede duplicar o eliminar cabeceras. Un balanceador puede verificar una autoridad y reenviar a otra. Nada obliga a que esos errores produzcan un mensaje distinto: precisamente pueden quedar ocultos tras el 404 esperado.

Cinco verificaciones no sustituyen la autorización

El backend comprueba sintaxis, existencia del ID, igualdad de claves, verificación del exporter y firma. Si algo falla, actúa como si no hubiera credencial. Si todo pasa, puede considerar autenticada la petición.

“Puede” es la frontera decisiva. La clave no concede todas las operaciones. Falta una decisión de autorización para el recurso y falta la ejecución. Un cliente puede estar correctamente autenticado y recibir una denegación. Puede pasar ambas etapas y encontrar una aplicación averiada. También puede llegar a una ruta expuesta que nunca ejecute Concealed.

Las métricas deben separar esos estados. Un 100 % de firmas válidas no prueba disponibilidad. Un 100 % de 404 uniformes puede esconder un rechazo universal.

Igual apariencia, distinta causa

No son suficientes el mismo código y la misma plantilla. Longitud, cabeceras, caché, cookies, cierre de conexión y tiempo pueden delatar el camino. La verificación criptográfica introduce coste; responder al path inventado de inmediato crea un diferencial.

La compensación de tiempo también tiene límites. Si todos los paths inexistentes reciben una pausa inusual, el retraso revela que el origen aplica una defensa especial. Las pruebas necesitan distribuciones, carga realista y múltiples ubicaciones.

Además, un enlace, un sitemap, un bundle del cliente, una página de ayuda, un evento analítico o un subdominio pueden publicar la existencia por otra vía. El esquema elimina el reto como oracle; no elimina la disciplina de contenidos y activos.

Los errata son un caso de prueba, no una nota al pie

El erratum verificado 8807 corrige el hexadecimal del contexto firmado. La figura publicada codificaba HTTP Signature Authentication, aunque el texto normativo exige HTTP Concealed Authentication. Copiar el vector equivocado produce una incompatibilidad que, desde fuera, se parece a cualquier ausencia.

El erratum 8843 sigue reportado y señala que el ABNF de s exige por error al menos dos dígitos no nulos, en tensión con el rango 0–65535. El despliegue debe documentar qué parser ejecuta y actualizar su matriz cuando cambie el estado del erratum.

Los registros IANA coordinan nombres. No son telemetría. La fila Concealed, la etiqueta de exporter y el campo permanente no dicen qué software los implementa ni qué rutas los ejecutan.

Ambigüedad afuera, contabilidad adentro

El plano privado debe conservar causas sin devolverlas al solicitante: ausente, mal formado, clave desconocida, clave revocada, clave pública distinta, exporter distinto, firma inválida, TLS inelegible, frontend no confiable, autorización denegada, ruta incorrecta o error de aplicación.

La correlación ha de estar protegida, limitada y auditada. No hace falta registrar claves ni cuerpos sensibles. Hace falta poder reconstruir la conexión, el frontend, las generaciones de configuración y la decisión.

Una matriz seria usa paths inexistentes como control; prueba ausencia de credencial, formato erróneo, IDs desconocidos y revocados, host y puerto equivocados, TLS 1.2 sin Extended Master Secret, campo exporter inyectado, proxies admitidos y no admitidos, y autenticación válida con permiso insuficiente. El exterior debe ver equivalencia donde corresponda. El interior debe ver diversidad causal.

Fuentes