Resumen

  • La revisión 01 del documento de casos de uso de SEAT distingue vínculo al canal, frescura, autenticación compuesta, atestación en ejecución y deriva de estado en conexiones largas o reanudadas.
  • TLS puede seguir protegiendo cada registro después de que cambie el entorno aceptado. El handshake demuestra una observación acotada, no una autorización permanente.

A las 09:00 un servicio establece TLS y presenta evidencia fresca ligada a esa conexión. El verificador acepta firmware, sistema, carga y controles. El relying party entrega un secreto. A las 14:00 el canal continúa cifrado, pero el workload migró, el agente de IA obtuvo otra herramienta o se desactivó una protección.

El canal hizo lo prometido. La máquina quizá dejó de cumplir la condición que justificó el acceso.

Ese es el límite temporal de draft-ietf-seat-use-cases-01, actualizado el 15 de septiembre de 2026 y con vencimiento el 19 de marzo de 2027. Es un Internet-Draft del grupo SEAT en I-D Exists. La portada indica Informational, Datatracker no muestra Intended RFC status y no registra shepherd, area director responsable ni telechat. No solicita acciones IANA. Define objetivos y casos de uso para una futura solución; no define el mecanismo, la política de appraisal, una implementación o un resultado operativo.

El canal y el entorno no son la misma identidad

TLS y DTLS autentican normalmente al par por una clave e identidad de red. La atestación remota aporta evidencia sobre Target Environment: hardware, firmware, software y configuración. Así, quien decide puede separar quién posee el canal de qué plataforma lo ejecuta y si ese estado resulta aceptable.

Un certificado válido no demuestra por sí solo que una clave siga siendo no exportable ni que secure boot esté activo. Una evidencia válida de una plataforma tampoco prueba que esa plataforma sea la dueña de la conexión donde apareció. Por ello la revisión 01 pide ligar criptográficamente Evidence o Attestation Result a la conexión específica.

La liga bloquea relay de evidencia auténtica procedente de otro contexto. El borrador también separa autenticación compuesta, identificador de máquina, autenticación ordinaria del peer y frescura de la credencial de atestación. Cada propiedad responde a una sustitución distinta.

Una evidencia fresca también envejece

La frescura dificulta reproducir un estado aceptable antiguo. El vínculo dificulta llevarlo a otro canal. Ambos prueban que una aserción suficientemente reciente bajo cierta regla pertenece a cierto contexto. No congelan el estado posterior.

El documento nombra la deriva en conexiones largas y reanudadas, incluye runtime attestation y separa modelos periódicos y bajo demanda. Una evidencia puede ser auténtica y volverse obsoleta sin que se rompa un solo MAC de TLS.

La configuración de un agente de IA puede cambiar sin alterar el binario: modelo, prompt, herramientas y permisos evolucionan con mayor frecuencia. También puede migrar un workload, revocarse un reference value o degradarse la protección de una clave. La capa de registros no está diseñada para detectar esos cambios.

La afirmación correcta tiene límites: un entorno fue evaluado bajo una política, una base de frescura y un instante, y el resultado se ligó a una conexión. “El canal continúa seguro” no significa “el endpoint continúa aceptable”.

Reanudar no es volver a medir

TLS resumption crea una conexión nueva a partir de estado previo. Puede mantener continuidad criptográfica, pero no resuelve si la evidencia sigue dentro de edad, si el Target Environment es el mismo, si política y verificador cambiaron o si un privilegio mayor exige otro control.

La revisión 01 exige considerar el caso sin imponer un número universal. Una lectura de telemetría y la entrega de una clave no toleran la misma antigüedad. Que el valor sea local no significa que pueda quedar implícito.

KeyUpdate también renueva claves de tráfico sin repetir el handshake. No vuelve a medir firmware, conjunto de herramientas o módulo criptográfico. Frescura de transporte, frescura de evidencia y frescura de autorización son tres relojes.

Passport y Background Check cambian el lugar del fallo

En RATS, Passport permite que el Attester obtenga un resultado y lo presente; Background Check hace que el relying party dependa del verificador. La revisión 01 asocia Background Check con máxima frescura y Passport con escala, rendimiento y funcionamiento cuando el verificador no está disponible.

Un pasaporte necesita caducidad y protección contra replay. Un background check necesita disponibilidad, latencia y una regla para timeout. Una vigencia breve reduce la ventana obsoleta, pero aumenta carga y denegación de servicio. Una vigencia larga mejora continuidad, pero prolonga la aprobación heredada.

Atestar con frecuencia tampoco es gratis para la privacidad. La evidencia puede revelar composición, versión, configuración o identidad de workload. Hay que decidir quién puede verla y cuánto se conserva, especialmente ante compromiso de claves efímeras o secretos de tráfico.

Las dos claves no fallan igual

Si se roba la clave de autenticación TLS, puede reubicarse en otra máquina. La atestación ayuda solo si vincula clave, entorno y conexión con suficiente precisión. Si se compromete la clave de atestación, puede falsificarse la evidencia misma; reforzar el canal no convierte al emisor comprometido en fuente fiable.

La atestación durante la emisión de un certificado tiene el mismo límite temporal. Puede demostrar dónde se generó y almacenó la clave en ese momento, no el estado del módulo cuando más tarde comienza la sesión ni durante todas sus horas.

Atestar no autoriza universalmente

Evidence y Attestation Results alimentan una política local. No son una orden de permitir. Una nueva medida puede ser válida y fallar una política actualizada. El mismo estado puede bastar para leer, no para recibir secretos. Una ausencia temporal del verificador puede llevar a modo degradado en un servicio y cierre inmediato en otro.

La especificación inicial mínima de Heng Lu favorece una semántica compartida de vínculo y frescura sin uniformar cada plataforma. La primacía del código exige recibos de que el sistema desplegado pidió nueva evidencia, invalidó la aprobación anterior y retiró derechos cuando llegó el evento.

Conviene registrar vínculo al transcript, identificadores de evidencia y resultado, nonce o base de frescura, verificador, generación de política, Target Environment, linaje de resumption y última aceptación. Los disparadores deben incluir migración, reanudación, aumento de privilegio, cambio de herramienta, rotación, alerta, revocación y edad máxima. Son recomendaciones operativas, no requisitos de la revisión 01.

El vínculo de canal cierra la sustitución. La reatestación y la retirada de autorización cierran el tiempo. Una organización que solo guarda el primer recibo confunde una observación válida con una propiedad permanente.

Fuentes