**Session Date/Time:** 17 Mar 2026 08:00

# [SEAT](../wg/seat.html)

## Summary

The SEAT (Secure Extension for Attested TLS) Working Group met at IETF 125 to discuss progress on use cases, security analyses of different attestation timing models, and several protocol proposals. A significant portion of the meeting focused on the security properties of intra-handshake attestation versus post-handshake attestation, specifically regarding relay and diversion attacks. The chairs emphasized that the use cases document should form the foundation for future protocol work. Formal verification (using Proverif) was a recurring theme in evaluating the security of the proposed binders.

## Key Discussion Points

### Working Group Administration and Use Cases
*   **Hannes Tschofenig** (Chair) reminded participants of the "Note Well" and established the priority of the use cases draft.
*   A poll was taken regarding the readiness of the use cases draft (currently `draft-ietf-seat-use-cases`) for adoption. The result showed 7 in favor, 0 against, and 13 with no opinion. An official adoption call will be moved to the mailing list.

### Security Analysis of Attestation Timing
**Presentation:** [security analysis](https://datatracker.ietf.org/meeting/125/materials/slides-125-seat-security-analysis-00)
*   **Osama Abbas** presented a security comparison between pre-, intra-, and post-handshake attestation. 
*   The analysis focused on "intra-handshake" attestation, deriving security goals from the "Agentic AI" use case. Formal analysis identified relay and diversion attacks on several existing intra-handshake implementations.
*   The core technical issue identified was binding evidence to an unauthenticated peer, as the server is not yet authenticated when the evidence is generated in many intra-handshake schemes.
*   **Tiru Reddy** questioned the threat model regarding private key leakage, arguing that if long-term keys are stolen, most protections fail. **Osama Abbas** clarified that the model distinguishes between ephemeral keys in a TEE and long-term cloud provider keys.

### Factor-based Attestation and Credentials Transport Scheme (FACTS)
**Presentation:** [FACTS SEAT IETF 125 Slides](https://datatracker.ietf.org/meeting/125/materials/slides-125-seat-facts-seat-ietf-125-slides-00)
*   **Nathaniel** introduced `draft-l-seat-facts`, a hybrid intra-handshake protocol designed to avoid modifying the TLS state machine or key schedule.
*   FACTS uses Key Encapsulation Mechanisms (KEM) to encapsulate nonces, providing a third layer of protection that allows security to hold even if two out of three keys (identity, attestation, or ephemeral) are compromised.
*   **Nathaniel** performed formal modeling using Proverif, finding that the binders in both FACTS and the latest version of Early Attestation (`draft-sheffer-seat-early-attestation-03`) appear to mitigate relay and diversion attacks.

### Remote Attestation with Exported Authenticators (X-PAT)
**Presentation:** [seat expat](https://datatracker.ietf.org/meeting/125/materials/slides-125-seat-seat-expat-00)
*   **Tiru Reddy** and **Osama Abbas** presented `draft-ietf-seat-remote-attestation-exported-authenticators`.
*   This is a post-handshake mechanism extending RFC 9261 (Exported Authenticators). It requires no changes to the TLS handshake and supports both background check and passport RATS models.
*   The draft allows for "re-attestation" during long-lived sessions without renegotiating the entire TLS connection.
*   **Jonathan Hammell** raised a technical question regarding whether the certificate request context provides bidirectional freshness/nonces. **Osama Abbas** clarified that in mutual attestation, both sides would exchange authenticator requests containing respective nonces.

### Early Attestation
**Presentation:** [Early Attestation](https://datatracker.ietf.org/meeting/125/materials/slides-125-seat-early-attestation-01)
*   **Yaron Sheffer** presented updates to `draft-sheffer-seat-early-attestation`.
*   To comply with the WG charter, the authors replaced the custom "attestation message" with an extension to the TLS Certificate message and decoupled the cryptographic binder from the TLS key schedule.
*   **Osama Abbas** challenged the claim of charter compliance, arguing that using KDFs to derive values still constitutes a modification or involvement with the key schedule. 
*   **Nathaniel** suggested that changing the terminology (avoiding the word "secret") might resolve the charter concerns while maintaining the same security properties.

## Decisions and Action Items
*   **Poll on Use Cases:** A sense of the room was taken regarding the adoption of `draft-ietf-seat-use-cases`. (7 Yes, 0 No).
*   **Protocol Consideration:** The chairs noted that protocol adoption will follow the formal adoption of the use cases document.

## Next Steps
*   **Mailing List:** The chairs will initiate a formal adoption call for the use cases draft on the SEAT mailing list.
*   **Charter Review:** The WG will continue to evaluate if intra-handshake proposals like `draft-sheffer-seat-early-attestation` and `draft-l-seat-facts` strictly adhere to the charter's prohibition on modifying the TLS key schedule.
*   **Formal Verification:** **Osama Abbas** and **Nathaniel** will collaborate offline to review and align their Proverif models for the various binding mechanisms.