WIMSE T. Reddy Internet-Draft Nokia Intended status: Standards Track N. Ritz Expires: 9 December 2026 Independent 7 June 2026 WIMSE Workload Attestation draft-reddy-wimse-workload-attestation-00 Abstract This document extends the WIMSE workload-to-workload authentication architecture with a mechanism for conveying attestation across TLS- terminating proxies, a deployment topology where TLS-layer attestation mechanisms lose their end-to-end security properties. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Reddy & Ritz Expires 9 December 2026 [Page 1] Internet-Draft WIMSE Attestation June 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The Workload-Evidence Header Field . . . . . . . . . . . . . 5 5. The Workload-Attestation-Result Header Field . . . . . . . . 5 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Background Check Model Protocol Flow . . . . . . . . . . 6 6.2. Passport Model Protocol Flow . . . . . . . . . . . . . . 7 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . . 8 9. Verification Algorithms . . . . . . . . . . . . . . . . . . . 8 9.1. Background Check Model (Workload-Evidence) . . . . . . . 9 9.2. Passport Model (Workload-Attestation-Result) . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10.1. Key Binding . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Stripping Attack . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix B. Document History . . . . . . . . . . . . . . . . . . 13 B.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Workloads communicate with each other over HTTPS. Securing these workload-to-workload calls requires answering two questions: who is the caller, and can the caller be trusted? Reddy & Ritz Expires 9 December 2026 [Page 2] Internet-Draft WIMSE Attestation June 2026 The first question is addressed by the WIMSE architecture [I-D.ietf-wimse-arch]. The Workload Identity Token (WIT) [I-D.ietf-wimse-workload-creds] carries the workload's identity, issued and signed by an Identity Server [I-D.ietf-wimse-arch]. The WIT embeds the workload's public key, the Identity Server's assertion that this key belongs to this workload. The WIT alone, however, does not prove that the presenter holds the corresponding private key; any party that intercepts the WIT could replay it. The Workload Proof Token (WPT) [I-D.ietf-wimse-wpt] closes this gap: it is a short-lived token signed by the workload's private key, bound to a specific HTTPS request and target URL, proving possession of the private key corresponding to the public key in the WIT. Together, the WIT and WPT establish both who the caller is and that the caller is the legitimate holder of that identity. Both travel as HTTP header fields and survive TLS termination at proxies. The second question, whether the caller's platform and key state can be trusted is not addressed by the WIT/WPT mechanism. A workload may have a valid identity and prove possession of its key, yet be running in a compromised environment, with a key that is not hardware- protected, or on a platform whose firmware or software does not meet the relying party's security policy. The SEAT Working Group is developing protocols that add attestation to TLS. [I-D.fossati-seat-early-attestation] introduces new TLS extensions that carry attestation Evidence or Attestation Results intra-handshake. [I-D.fossati-seat-expat] provides post-handshake attestation using TLS Exported Authenticators. Both mechanisms are designed so that Evidence is cryptographically tied to a specific TLS connection. However, this same property is their limitation when TLS does not extend end-to-end to the backend workload, as described in [I-D.ietf-wimse-arch]. The attestation binding does not reach the backend, and the backend workload receives no cryptographic evidence of the original caller's platform and key state. Since the WIT and WPT already travel end-to-end as HTTP headers through TLS-terminating proxies, attestation information can travel alongside them in the same way. This document supports both the background check model and the passport model [RFC9334]. In both cases, the workload's public key is the binding element across the WIT, WPT, and the attestation information. This requires no changes to TLS, no changes to proxy infrastructure, and no modifications to the WIT or WPT specifications. Reddy & Ritz Expires 9 December 2026 [Page 3] Internet-Draft WIMSE Attestation June 2026 For the key binding verification to be cryptographically meaningful, the Evidence needs to contain a public-key confirmation claim corresponding to the workload's public key, and claims describing the protection properties of the associated private key. [RFC9711] illustrates how a key and key store may be represented in Evidence in Appendix A.1.4, but uses private-use claim labels and does not define standardised key-protection claims. One way to satisfy these requirements is the profile defined in [I-D.reddy-rats-key-binding]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals as shown here. 2. Terminology This document uses terms defined in the WIMSE Architecture [I-D.ietf-wimse-arch] and the RATS Architecture [RFC9334]. Workload Identity Token (WIT): A JWT that represents the identity of a workload and binds a public key to that identity, as defined in [I-D.ietf-wimse-workload-creds]. Workload Proof Token (WPT): A JWT that provides proof of possession of the private key associated with a WIT, as defined in [I-D.ietf-wimse-wpt]. TLS-terminating proxy: An intermediary that terminates the caller's TLS connection and establishes a new, independent TLS connection to the backend workload. Workload Evidence (WE): Attestation Evidence generated by the workload's TEE, signed by the Attestation Key, and carried in the Workload-Evidence HTTP header field as defined in this document. Evidence freshness is provided by using the WPT jti claim [I-D.ietf-wimse-wpt] as the nonce during Evidence collection. Workload EAR (WEAR): An EAT Attestation Result (EAR) [I-D.ietf-rats-ear] generated by a Verifier following appraisal of the workload's Evidence, and carried in the Workload-Attestation- Result HTTP header field as defined in this document. Request binding is provided by using the WPT jti claim [I-D.ietf-wimse-wpt] as the nonce during Evidence collection, which the Verifier echoes in the eat_nonce claim of the EAR. Reddy & Ritz Expires 9 December 2026 [Page 4] Internet-Draft WIMSE Attestation June 2026 3. Scope This document specifies mechanisms for conveying workload attestation information alongside WIMSE workload-to-workload HTTP requests, supporting both the background check model and the passport model [RFC9334]. 4. The Workload-Evidence Header Field The Workload-Evidence header field carries Evidence generated by the workload's TEE. The Evidence MUST be encapsulated in a CMW (Conceptual Message Wrapper) [I-D.ietf-rats-msg-wrap]. The CMW type field identifies the attestation technology and serialization format, providing interoperability at the envelope level without out-of-band negotiation. The Evidence MUST contain: * a public-key confirmation claim corresponding to the workload's public key, and * claims describing the protection properties of the associated private key. One way to satisfy these requirements is the profile defined in [I-D.reddy-rats-key-binding]. The three header fields form a coherent set, each independently signed by a different authority: +----------------------------+------------------+---------------------------+ | Header field | Signer | Binds to | +----------------------------+------------------+---------------------------+ | Workload-Identity-Token | Identity Server | Workload identity | | Workload-Proof-Token | Workload | Private key + Target URI | | Workload-Evidence | TEE (AK) | Platform + key | +----------------------------+------------------+---------------------------+ The workload's public key is the binding across all three: it is asserted by the Identity Server in the WIT, proven in possession by the WPT, and attested as hardware-protected by the Evidence. 5. The Workload-Attestation-Result Header Field When the passport model is used, the Workload-Attestation-Result header field carries the EAT Attestation Result (EAR) generated by the Verifier [I-D.ietf-rats-ear]. Reddy & Ritz Expires 9 December 2026 [Page 5] Internet-Draft WIMSE Attestation June 2026 The EAR MUST contain the ear_verified_attester_key claim. This claim provides the Relying Party with the verified public key of the attester. Because the ear_verified_attester_key claim is represented as a PEM-encoded SPKI or certificate, and the WIT carries the workload's public key as a JWK [I-D.ietf-wimse-workload-creds], implementations MUST convert between the two formats to perform the required cryptographic comparison. The EAR MUST also contain the eat_nonce claim, set to the nonce value extracted from the appraised Evidence. Because the workload uses the WPT jti claim as the Evidence nonce, this value enables the Relying Party to verify that the EAR was produced from Evidence collected for this specific request. +-----------------------------+------------------+---------------------------+ | Header field | Signer | Binds to | +-----------------------------+------------------+---------------------------+ | Workload-Identity-Token | Identity Server | Workload identity | | Workload-Proof-Token | Workload | Private key + Target URI | | Workload-Attestation-Result | Verifier | Appraised platform + key | +-----------------------------+------------------+---------------------------+ Similar to the background check model, the workload's public key acts as the binding element: it is asserted by the Identity Server in the WIT, proven in possession by the WPT, and verified by the Verifier in the EAR. 6. Protocol Flows 6.1. Background Check Model Protocol Flow Reddy & Ritz Expires 9 December 2026 [Page 6] Internet-Draft WIMSE Attestation June 2026 Caller (TEE Workload) Backend Workload | | | [Startup] | | Generate key pair inside TEE | | Obtain WIT from Identity Server | | | | [Per-request] | | Construct WPT, generate jti | | Collect Evidence using jti as nonce | | Sign WPT with private key | | | |------ HTTPS Request ----------------->| | Workload-Identity-Token: | | Workload-Proof-Token: | | Workload-Evidence: | | | | Verify WIT | | Verify WPT | | Submit Evidence | | + jti + WIT key | | to Verifier | | Evaluate policy | | | |<------ Response ----------------------| 6.2. Passport Model Protocol Flow In the passport model, the caller obtains the Attestation Result from a Verifier before initiating the request to the backend workload. The caller uses the WPT jti claim as the challenge when requesting the EAR. Reddy & Ritz Expires 9 December 2026 [Page 7] Internet-Draft WIMSE Attestation June 2026 Caller (TEE Workload) Verifier Backend Workload | | | | [Startup] | | | Generate key pair inside TEE | | | Obtain WIT from Identity Server | | | | | | [Per-request] | | | Construct WPT, generate jti | | | Collect Evidence (jti as nonce) | | | Submit Evidence to Verifier --->| | | | Verify Evidence | |<----- Return EAR (w/ key) ------| | | Sign WPT with private key | | | | | |------ HTTPS Request --------------------------------->| | Workload-Identity-Token: | | Workload-Proof-Token: | | Workload-Attestation-Result: | | | | Verify WIT | | Verify WPT | | Verify EAR sig | | Verify key in | | EAR matches WIT | | Evaluate policy | | | |<------ Response --------------------------------------| 7. Applicability The Workload-Evidence and Workload-Attestation-Result header fields defined in this document are applicable to both WIMSE application- level protection mechanisms: WPT [I-D.ietf-wimse-wpt] and HTTP Signatures [I-D.ietf-wimse-http-signature]. 8. Proxy Behaviour A TLS-terminating proxy MUST forward the Workload-Evidence and Workload-Attestation-Result header fields unchanged toward the backend workload. A proxy MUST NOT strip or modify the Workload- Evidence or Workload-Attestation-Result header fields. 9. Verification Algorithms The backend workload acts as the Relying Party as defined in [RFC9334] and submits Evidence to a Verifier for appraisal. Reddy & Ritz Expires 9 December 2026 [Page 8] Internet-Draft WIMSE Attestation June 2026 The backend workload MUST first verify the WIT and WPT as defined in [I-D.ietf-wimse-wpt]. Following this, it MUST perform the steps for either the Background Check Model or the Passport Model, depending on which header is presented. For both models, the request MUST NOT be processed further until all steps have completed successfully. If a backend workload requires attestation by policy, it MUST reject any request that does not include either a valid Workload-Evidence or Workload-Attestation- Result header field with a 403 Forbidden status code. If a request contains both Workload-Evidence and Workload- Attestation-Result header fields, the backend MUST reject the request with 400 Bad Request. 9.1. Background Check Model (Workload-Evidence) 1. Extract the Workload-Evidence header field value. 2. Decode the CMW wrapper to determine the Evidence format from the CMW type field. 3. Convert the WIT public key to the format indicated by the CMW type field. 4. Submit the Evidence, the WPT jti, and the converted WIT public key to a Verifier. 5. The Verifier MUST verify that the nonce carried in the Evidence matches the submitted jti. 6. The Verifier MUST verify that the public key in the Evidence matches the submitted WIT public key. 7. Evaluate the returned Attestation Result against local policy. 9.2. Passport Model (Workload-Attestation-Result) 1. Extract the Workload-Attestation-Result header field value. 2. Verify the digital signature of the EAR using the Verifier's public key or trust anchor. 3. Verify that the ear_verified_attester_key claim is present in the EAR Appraisal record. Reddy & Ritz Expires 9 December 2026 [Page 9] Internet-Draft WIMSE Attestation June 2026 4. Convert the PEM-encoded SPKI or certificate from the ear_verified_attester_key claim and the JWK from the WIT into a common format. 5. Verify that the converted public key from the EAR matches the public key in the WIT. 6. Verify that the eat_nonce claim in the EAR matches the jti claim from the WPT. 7. Evaluate the EAR against local policy. 10. Security Considerations 10.1. Key Binding The security of this mechanism depends on verifying that the public key in the Evidence matches the public key in the WIT. This ensures the Evidence is about the same key that the WPT proves possession of. One way to satisfy the key binding requirements is the profile defined in [I-D.reddy-rats-key-binding]. 10.2. Stripping Attack A malicious proxy may strip the Workload-Evidence or Workload- Attestation-Result header fields. Backend workloads that require attestation by policy MUST reject requests lacking the required valid Workload-Evidence or Workload-Attestation-Result header field with a 403 Forbidden status code. 11. IANA Considerations This document requests registration of the following HTTP header fields in the "HTTP Field Names" registry: Field Name: Workload-Evidence Status: permanent Specification Document: This document Field Name: Workload-Attestation-Result Status: permanent Specification Document: This document Reddy & Ritz Expires 9 December 2026 [Page 10] Internet-Draft WIMSE Attestation June 2026 12. References 12.1. Normative References [I-D.ietf-rats-ear] Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT Attestation Results", Work in Progress, Internet-Draft, draft-ietf-rats-ear-04, 26 May 2026, . [I-D.ietf-rats-msg-wrap] Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23, 11 December 2025, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-07, 2 March 2026, . [I-D.ietf-wimse-workload-creds] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-01, 5 May 2026, . [I-D.ietf-wimse-wpt] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-01, 2 March 2026, . [I-D.reddy-rats-key-binding] Reddy.K, T., Tschofenig, H., Fossati, T., and I. Mihalcea, "Key Attestation for Entity Attestation Tokens (EAT)", Work in Progress, Internet-Draft, draft-reddy-rats-key- binding-01, 7 June 2026, . Reddy & Ritz Expires 9 December 2026 [Page 11] Internet-Draft WIMSE Attestation June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . 12.2. Informative References [I-D.fossati-seat-early-attestation] Sheffer, Y., Mihalcea, I., Deshpande, Y., Fossati, T., and T. Reddy.K, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-seat-early- attestation-04, 27 May 2026, . [I-D.fossati-seat-expat] Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y., Tschofenig, H., and I. Mihalcea, "Remote Attestation with Exported Authenticators", Work in Progress, Internet- Draft, draft-fossati-seat-expat-02, 26 February 2026, . Reddy & Ritz Expires 9 December 2026 [Page 12] Internet-Draft WIMSE Attestation June 2026 [I-D.ietf-wimse-http-signature] Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-03, 7 April 2026, . Appendix A. Acknowledgements The authors would like to thank Thomas Fossati and Ionut Mihalcea for the review and comments, and the SEAT Working Group participants for discussions that motivated this work. Appendix B. Document History B.1. Version -00 * Initial version Authors' Addresses Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: kondtir@gmail.com Nathanael Ritz Independent Email: ietf@nritz.com Reddy & Ritz Expires 9 December 2026 [Page 13]