A new IETF WG has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs.
NOTE: This group went through the chartering process as "Secure Evidence and Attestation Layer (SEAL)" and then changed to "Secure Evidence and Attestation Transport (SEAT)" upon approval. Please see https://datatracker.ietf.org/doc/charter-ietf-seal/ for the ballots about this chartering process. Secure Evidence and Attestation Transport (seat) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Yaroslav Rosomakho <[email protected]> Nancy Cam-Winget <[email protected]> Assigned Area Director: Paul Wouters <[email protected]> Security Area Directors: Paul Wouters <[email protected]> Deb Cooley <[email protected]> Mailing list: Address: [email protected] To subscribe: https://mailman3.ietf.org/mailman3/lists/seat.ietf.org/ Archive: https://mailarchive.ietf.org/arch/browse/seat Group page: https://datatracker.ietf.org/group/seat/ Charter: https://datatracker.ietf.org/doc/charter-ietf-seat/ # Background and motivation In many scenarios, particularly with the rise of Trusted Execution Environments (TEEs) and the increasing security demands for IoT devices and confidential workloads, there is a requirement for some use cases that utilize protocols such as (D)TLS to also ensure that the peer's state, expressed as Claims (for example about code, data and configurations), is validated and when authenticating, also bound to the conventional authentication (verification of identity). Remote attestation (RFC9334) addresses this by allowing an entity to produce Evidence and Attestation Results about its current state. For example to prove that its software and firmware haven't been tampered with. Or to prove that a secure boot method is enabled. Or to prove that cryptographic keys are securely stored within a hardware-protected environment. Remote attestation bound to the authenticated TLS connection provides an additional assurance of trustworthiness that can prevent communication to a compromised or unauthorized system. # Scope The Secure Evidence and Attestation Transport (SEAT) WG will document a set of use cases that protocols such as (D)TLS should be able to support. It will initially deliver a Standards Track protocol that meets these use cases and enables peer or mutual attestation for (D)TLS using the extension and/or exporter features of D(TLS). Mutual attestation will be supported with and without client TLS authentication to faciliate anonymous client attestation. Such a protocol would allow an entity to produce Evidence or an Attestation Result about itself for another party to evaluate. Specific scoping: - This effort will be restricted to leveraging the (D)TLS 1.3 protocol and an attestation binding to a (D)TLS 1.3 connection. (D)TLS 1.2 and older will not be supported. - It will leverage the existing RATS WG documents to ensure interoperability with existing and future attestation technologies. - The attested (D)TLS protocol extension will focus on attestation with TLS server authentication, and with or without TLS client authentication. No new TLS authentication mechanisms will be created. - The attested (D)TLS protocol extension will not modify the (D)TLS protocol itself. It may define (D)TLS extensions to support its goals but will not modify, add, or remove any existing protocol messages or modify the key schedule. - The attested D(TLS) protocol extension will also describe a minimum subset of properties that the attested state must convey in order to bind the Evidence and Attestation Results to the TLS connection. - The attested (D)TLS protocol extension will allow per-connection [freshness] (https://www.ietf.org/rfc/rfc9334.html#section-10) of Evidence and Attestation Results. - The effort will not create solutions that decrease the privacy or security properties of generic (D)TLS connections. The working group will engage with the research community on the evaluation and formal analysis of the protocol artifacts in parallel with the specification work. # Dependencies and Liaisons - The working group will work closely with the TLS Working Group, the RATS working group, and the Confidential Computing Consortium's (CCC's) Attestation Special Interest Group (SIG). - The working group will engage with research groups regarding formal analysis of the working groups's resulting work. # Future work After the initial Milestones are complete, the WG may recharter to work on adding attestation to protocols other than (D)TLS, such as IKEv2 or SSH, provided there is sufficient interest. Milestones: - A use cases document describing the scenarios that this working group will be targeting in its specification document. This document need not be published as an RFC. - A Standards Track document defining an attested (D)TLS protocol extension supporting remote peer and mutual attestation bound to the (D)TLS connection. _______________________________________________ IETF-Announce mailing list -- [email protected] To unsubscribe send an email to [email protected]
