Resumen

  • draft-ietf-kitten-sasl-ht-02 propone una familia SASL de dos mensajes para reautenticar con un token efímero. Los HMAC del iniciador y del respondedor incluyen datos de vinculación al canal y parejas clave/valor opcionales.
  • La revisión 02 es un Internet-Draft activo del grupo KITTEN, en última llamada del grupo, con estado previsto Proposed Standard y vencimiento el 24 de diciembre de 2026. No es una RFC ni una constatación de despliegue.
  • Incluir un campo en el HMAC prueba integridad y atribución al poseedor del token. No define el campo, no demuestra que su valor esté permitido y no concede el privilegio que solicita.
  • La operación segura conserva recibos distintos para emisión y fijación del token, selección del vínculo de canal, verificación en ambos sentidos, control de repetición, consumo o revocación, interpretación de campos, autorización vigente, transición de sesión y resultado.

La autenticidad responde quién dijo algo, no quién manda

SASL-HT permite que ambos mensajes lleven valores auxiliares. El iniciador incorpora sus parejas clave/valor al material del HMAC; el respondedor hace lo mismo con las suyas. Si cambia un octeto, la verificación deja de corresponder. El mecanismo ofrece así una forma compacta de autenticar contexto junto con la prueba de posesión.

Ese resultado tiene un límite institucional. Una identidad puede pedir auténticamente resume_generation=x, role=administrator o cualquier otra clave que la extensión admita sintácticamente. La firma de la petición no convierte el valor en política. El servidor todavía debe saber si reconoce la clave, si el tipo y la versión son válidos, si la identidad puede afirmarla, si contradice estado más reciente y qué acción —si alguna— produce.

La confusión aparece cuando el registro reduce todo a “campo autenticado”. En una auditoría posterior ya no se puede distinguir entre cuatro hechos: el cliente envió esos bytes; el servidor conocía su esquema; la política autorizó el valor; la aplicación ejecutó la transición. Un HMAC solo resuelve el primero y protege el transporte del campo dentro de su cálculo.

Por eso el recibo útil guarda un hash del mensaje exacto, la versión de esquema, la regla de admisión, el sujeto y servicio vinculados al token, la decisión de autorización y el identificador del cambio de estado. No hace falta registrar el secreto. Sí hace falta poder señalar dónde terminó la evidencia.

El token también tiene un origen que debe ser probado

El proyecto exige que una extensión del protocolo de aplicación permita solicitar el token. El token devuelto debe ser recién generado por un generador criptográficamente seguro y contener al menos 128 bits de entropía. Además, se recomienda que el solicitante declare el mecanismo SASL previsto y que usar el token con otro mecanismo provoque un fallo.

Aleatoriedad y fijación de mecanismo son controles distintos. La primera dificulta adivinar el secreto. La segunda impide trasladarlo a una variante no acordada. Ninguna demuestra que la autenticación anterior fue la adecuada, que el emisor estaba facultado para crear el token, que el token corresponde al servicio correcto o que el privilegio original sigue vigente.

Una plataforma distribuida debe preservar la genealogía: método fuerte anterior, instante y autoridad de emisión, authcid, servicio, mecanismo fijado, límite temporal o de uso y generación de sesión. Si un verificador solo conserva el secreto o su derivado, puede validar posesión sin saber qué promesa originó el registro.

El propio texto recomienda volver periódicamente a una autenticación fuerte que no dependa del token HT. Esa recomendación reconoce que una prueba rápida no debe convertirse silenciosamente en raíz permanente. El intervalo es una decisión local que requiere reloj, política y observación.

Cuatro nombres de mecanismo, cuatro afirmaciones distintas

Los nombres de la familia comienzan con HT2-, añaden el algoritmo hash y terminan en ENDP, UNIQ, EXPR o NONE. Cada sufijo selecciona una entrada de vinculación al canal; NONE usa una cadena vacía. Un resultado válido con NONE no contiene evidencia de las otras vinculaciones.

La telemetría debe registrar el nombre completo y no una etiqueta genérica como “SASL-HT seguro”. Cuando una política exige exporter TLS, aceptar NONE porque el HMAC coincide elimina el requisito después de los hechos. Tampoco basta observar EXPR: hay que conservar qué identidad TLS se verificó y qué conexión produjo la entrada, mediante un recibo que no exponga material reutilizable.

La variante elegida también entra en la relación con el token emitido. Si la extensión permitió fijar el mecanismo, todos los verificadores deben consultar ese atributo. Una réplica que conoce el token pero no su pin puede aprobar una prueba matemáticamente correcta bajo una política equivocada.

La prueba del iniciador es solo la primera mitad

El iniciador calcula un HMAC con la cadena de rol Initiator, la entrada de canal y sus valores. El servidor lo recalcula y compara; si difiere, la autenticación debe fallar. Si coincide, el servidor prepara un mensaje de éxito con la cadena de rol Responder, la misma clase de contexto y sus propios valores.

El cliente debe verificar ese segundo HMAC para obtener autenticación mutua. Un éxito almacenado únicamente en el servidor no demuestra que el cliente reconoció al respondedor. Puede haber una pérdida de red después del envío, un error de análisis o un cliente que continúe indebidamente sin verificar.

La diferencia cambia el tratamiento de los reintentos. El servidor quizá consumió el token; el cliente quizá no sabe si el intento terminó; otra réplica quizá todavía lo considera disponible. Registrar “éxito” sin dirección, momento y confirmación oculta la incertidumbre que gobierna el siguiente intento.

Un token de vida corta necesita estado compartido

El borrador recomienda que los tokens tengan vida limitada por tiempo o número de usos y que la extensión permita rotación o revocación. Su ejemplo muestra al servicio revocando el token tras un uso exitoso. La secuencia expresa una intención de diseño, no prueba que una escritura se haya confirmado en todas las réplicas.

La política debe decidir cuándo se consume. Reservar antes de verificar evita dobles éxitos, pero puede quemar un token por un intento fallido. Consumir después de emitir la respuesta abre una ventana entre resultado y persistencia. Una transacción local no basta si otras regiones verifican el mismo registro.

La respuesta no consiste siempre en consistencia global máxima. Consiste en relacionar el costo de una doble aceptación con la operación posterior. Si la reautenticación solo abre una sesión nueva sujeta a autorización, quizá se tolere un retry. Si restaura una consola capaz de ejecutar cambios irreversibles, la reserva y la convergencia necesitan una garantía más fuerte.

La observación debe separar expiración, contador, reserva, consumo, revocación, replicación y rechazo. Un panel que solo muestra “token inválido” no puede distinguir una defensa correcta de una partición o de un error de reloj.

El 0-RTT no adelanta la autoridad de la aplicación

El mensaje del iniciador puede viajar como datos tempranos de TLS 1.3. El proyecto prohíbe añadir otra carga de aplicación, salvo el encuadre indispensable, y exige abortar SASL si aparece. La razón es que los datos tempranos pueden ser repetidos.

Esto permite tratar la prueba como operación idempotente bajo controles de uso. No permite colocar una orden, mutación o efecto detrás de ella y llamarlo seguro porque el HMAC era válido. El servidor debe completar la comprobación de repetición y la autorización vigente antes de admitir trabajo no idempotente.

Incluso una respuesta rápida del servidor mantiene dos pasos: el cliente verifica el HMAC del respondedor y la aplicación decide qué significa el contexto devuelto. La reducción de viajes de red no reduce el número de autoridades que intervienen.

Autenticación no transporta authzid

El borrador declara que HT no puede llevar una identidad de autorización y no protege una. También aclara que no ofrece una capa de seguridad SASL: ofrece vinculación al canal. Estas limitaciones impiden usar el éxito como sustituto de la decisión de privilegios.

authcid identifica la cuenta que presenta la prueba. El servidor aún debe mapearla a estado actual, bloqueos, cambios de rol, alcance del servicio y la acción solicitada. Un token emitido antes de retirar un privilegio puede seguir siendo criptográficamente válido. La autorización debe observar el presente, no congelar el pasado de la emisión.

El mismo límite rige para reanudar una sesión. La posesión no contiene la cola, el cursor, la versión del documento o el bloqueo que se espera recuperar. La aplicación necesita identificar la generación, comprobar su pertenencia y decidir entre restaurar, crear una sesión nueva o exigir autenticación completa.

El recibo que permite responder después

Un registro defendible enlaza, sin revelar el token, la emisión, el método anterior, el sujeto, el servicio, el mecanismo fijado, el límite temporal y de uso, la identidad TLS, el tipo de canal, los hashes de ambos mensajes, los campos auxiliares y su esquema, la reserva contra repetición, la revocación, la política de autorización, la generación de sesión y el resultado observado.

También conserva las incertidumbres. Una descripción externa other-error puede ocultar la causa para evitar filtración; el registro interno protegido debe mantenerla. Un mensaje del respondedor enviado pero no verificado no es autenticación mutua completa. Una revocación local sin confirmación de réplicas no es consumo global.

El objetivo no es llenar un lago de datos. Es conservar las uniones decisivas para que una frase exacta siga siendo posible: «estos bytes fueron autenticados» sin convertirla en «esta orden estaba autorizada».

Fuentes