Network Time Protocols R. Krishnan Internet-Draft JPMorgan Chase Intended status: Informational M. Richardson Expires: 2 September 2026 Sandelman Software Works Inc D. Lopez Telefonica A. Prasad Oracle S. Addepalli Aryaka 1 March 2026 Hardware-Rooted Attestation for Precision Time Protocol: Scalable Workload Identity and Phased PQC Readiness draft-ramki-ptp-hardware-rooted-attestation-01 Abstract This document defines a scalable framework for hardware-rooted cryptographic attestation in the Precision Time Protocol (PTP). Standard PTP security mechanisms rely on symmetric keys, which suffer from identity ambiguity and source non-repudiation failures—vulnerabilities that allow any node possessing the shared secret to impersonate a Grandmaster. To resolve these issues while overcoming the silicon throughput limits of traditional TPMs and the overhead of Post-Quantum Cryptography (PQC), this draft specifies a tiered trust model. A Hardware Root (e.g., TPM) establishes a long- term PQC identity, while a workload identity management plane (e.g., SPIFFE/SPIRE) manages the frequent rotation of short-lived operational keys. These keys perform amortized signing of PTP message batches via Merkle Trees, ensuring wire-speed synchronization and irrefutable provenance for regulated environments. 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." Krishnan, et al. Expires 2 September 2026 [Page 1] Internet-Draft PTP-Hardware-Rooted-Attestation March 2026 This Internet-Draft will expire on 2 September 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Architecture: The Tiered Trust Model . . . . . . . . . . . . 3 2.1. Tier 1: Hardware Root (Immutable Identity) . . . . . . . 3 2.2. Tier 2: Control Plane (Workload Orchestration) . . . . . 4 2.3. Tier 3: Data Plane (Amortized Execution) . . . . . . . . 4 3. Scalable Attestation Mechanism . . . . . . . . . . . . . . . 4 3.1. Solving Source Non-Repudiation . . . . . . . . . . . . . 4 3.2. Amortized PQC Readiness . . . . . . . . . . . . . . . . . 4 4. Signed Token Structure (CBOR) . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5.1. Integrity vs. Network Jitter . . . . . . . . . . . . . . 5 5.2. Symmetric Key Obsolescence . . . . . . . . . . . . . . . 5 5.3. Network Path Asymmetry . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Precise, auditable time provenance is a cornerstone for regulated environments, including financial services, distributed ledgers, and sovereign AI. However, standard PTP security (IEEE 1588-2019) faces three critical architectural challenges: 1. *The Identity and Non-Repudiation Problem:* Current PTP security relies largely on symmetric keys (HMAC-SHA256). Because the Grandmaster (GM) and all Slaves share the same secret, any compromised node can forge time messages appearing to originate Krishnan, et al. Expires 2 September 2026 [Page 2] Internet-Draft PTP-Hardware-Rooted-Attestation March 2026 from the GM. This lack of source non-repudiation makes it impossible to irrefutably audit time provenance or defend against "insider" clock spoofing. 2. *The Throughput Gap:* Hardware Security Modules (TPMs) are "slow- path" silicon, often constrained to tens-to-hundreds of asymmetric operations per second — insufficient for high- performance PTP profiles that may require sustained high- frequency signing. 3. *The PQC Payload Problem:* Post-Quantum Cryptographic (PQC) signatures (e.g., ML-DSA) are significantly larger than standard PTP message MTUs, introducing fragmentation risks and unacceptable processing jitter if applied per-packet. This draft introduces a *Transitive and Amortized Attestation* model. Amortization, in this context, refers to spreading the cost of a single cryptographic signature across many PTP messages by signing only the root of their Merkle hash tree. By anchoring an automated software control plane in hardware silicon, we resolve the identity ambiguity of symmetric keys while maintaining wire-speed performance. 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. Architecture: The Tiered Trust Model Trust is distributed across three functional layers to bridge the gap between "Slow-but-Secure" hardware and "Fast-and-Precise" network timing. 2.1. Tier 1: Hardware Root (Immutable Identity) The Root of Trust (RoT) is a hardware component (e.g., TPM 2.0, HPE iLO 7, or SmartNIC SRoT) containing a non-exportable Identity Key. This key MUST be asymmetric and SHOULD be PQC-compatible (e.g., ML- DSA). This establishes an irrefutable "Silicon Identity" that cannot be cloned, addressing the fundamental weakness of symmetric shared secrets. Krishnan, et al. Expires 2 September 2026 [Page 3] Internet-Draft PTP-Hardware-Rooted-Attestation March 2026 2.2. Tier 2: Control Plane (Workload Orchestration) To manage the lifecycle of cryptographic material without manual intervention, the PTP daemon is treated as a managed workload under workload identity management frameworks such as *SPIFFE/SPIRE*. * *Attestation:* The host identity management plane (e.g., HPE OneView, Keylime verifier/registrar) MUST verify the RoT's identity and platform state (PCRs) before authorizing key issuance. The interaction between the host identity management plane and the workload identity management plane for attesting the workload identity agent is described in {{GEO-FENCE}}. * *Delegation:* Upon successful attestation, the Workload identity management plane (e.g., SPIFFE/SPIRE) issues short-lived SVIDs and ephemeral *Operational Keys* which use standard non-PQC cryptography. This "Transitive Attestation" binds the high-speed software/NIC key to the immutable hardware identity. 2.3. Tier 3: Data Plane (Amortized Execution) High-frequency signing is offloaded to the Data Plane using the *Operational Keys* in software or a hardware offload such as SmartNIC. * *Merkle Batching:* PTP messages are hashed into a Merkle Tree. A single signature on the Merkle Root provides cryptographic integrity and non-repudiation proof for the entire batch of PTP events. A batch is flushed and transmitted to the receiver when either the configured batch size N is reached or a maximum latency timer T expires, whichever comes first. This amortization makes large PQC signatures feasible within the PTP ecosystem. 3. Scalable Attestation Mechanism 3.1. Solving Source Non-Repudiation By utilizing asymmetric operational keys certified by the Hardware Root, a Verifier can irrefutably prove that a batch of PTP messages originated from a specific physical device. In this model, a compromised Slave has no access to the private key required to forge a GM's signature, fixing the identity ambiguity inherent in current symmetric PTP profiles. 3.2. Amortized PQC Readiness PQC adoption is phased to ensure that data-plane performance is never compromised: 1. *Identity Layer:* RECOMMENDED to use PQC-capable hardware roots (Identity Key) today to secure the long-term device identity. 2. *Control Layer:* RECOMMENDED to use PQC-signed workload identities (e.g., SPIFFE/SPIRE SVIDs) to protect the distribution and rotation of keys. 3. *Data Layer:* MAY use classical asymmetric Krishnan, et al. Expires 2 September 2026 [Page 4] Internet-Draft PTP-Hardware-Rooted-Attestation March 2026 algorithms (e.g., Ed25519) for the Merkle Root today, transitioning to PQC as specialized hardware acceleration becomes pervasive. 4. Signed Token Structure (CBOR) The amortized token provides the "Batch Proof" for a set of N consecutive sequence IDs between a single sender <-> receiver pair. The token is created by the signing entity (GM or boundary clock) at batch flush time and validated by the receiver. The signature field (key 7) covers the canonical CBOR encoding of fields 1 through 6. ; Amortized Signed Token (CBOR map) { 1 : uint, ; version (e.g., 2) 2 : uint, ; batch_size (N) 3 : bstr, ; Merkle Root Hash 4 : uint, ; First SequenceID in batch 5 : bstr, ; Operational Key ID / Certificate Thumbprint 6 : bstr, ; nonce (verifier-issued) 7 : bstr ; signature over fields 1-6 (PQC recommended) } 5. Security Considerations 5.1. Integrity vs. Network Jitter PQC signatures are computationally heavy. Performing these on every packet would introduce variable jitter into the PTP timing loop. The amortized Merkle approach ensures that the timing-sensitive hardware timestamping remains asynchronous from the heavy cryptographic signing process. 5.2. Symmetric Key Obsolescence Symmetric-key PTP security is insufficient for regulated time provenance due to the lack of source non-repudiation. This draft provides the blueprint for transitioning to asymmetric hardware- rooted keys as the only viable path to meaningful identity in multi- tenant or untrusted fabrics. 5.3. Network Path Asymmetry Attestation provides proof of Identity, Integrity, and Residency. It does not protect against physical network delay or path asymmetry. This mechanism MUST be used in conjunction with PTP's native delay measurement mechanisms. Krishnan, et al. Expires 2 September 2026 [Page 5] Internet-Draft PTP-Hardware-Rooted-Attestation March 2026 6. IANA Considerations This document requests IANA to create a new registry named "PTP Amortized Attestation TLV Types" under an appropriate PTP-related registry group. The registry MUST define the following fields for each entry: * *TLV Type:* A unique unsigned integer identifier. * *Name:* A descriptive name (e.g., PTP_AMORTIZED_ATTESTATION_TLV). * *Reference:* The RFC or specification defining the TLV. Initial allocations in this registry are defined in this document. Future allocations SHALL follow the Specification Required policy as defined in {{!RFC8126}}. 7. References 7.1. Normative References [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE 1588-2019, 2019. [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, https://www.rfc-editor.org/info/rfc8949 (https://www.rfc-editor.org/info/rfc8949). [FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard (ML-DSA)", FIPS 204, 2024. [SPIFFE] SPIFFE Project, "Secure Production Identity Framework for Everyone (SPIFFE) Specification", https://github.com/spiffe/spiffe (https://github.com/spiffe/spiffe). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119 (https://www.rfc- editor.org/info/rfc2119). [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174 (https://www.rfc- editor.org/info/rfc8174). [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/ rfc8126 (https://www.rfc-editor.org/info/rfc8126). 7.2. Informative References [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Krishnan, et al. Expires 2 September 2026 [Page 6] Internet-Draft PTP-Hardware-Rooted-Attestation March 2026 W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, https://www.rfc- editor.org/info/rfc9334 (https://www.rfc-editor.org/info/rfc9334). [GEO-FENCE] Krishnan, R., et al., "Verifiable Geo-Fence for Workload Identity", Work in Progress, Internet-Draft, draft-lkspa-wimse- verifiable-geo-fence, https://github.com/ramkri123/ietf-tpm- geofencing/blob/master/draft-lkspa-wimse-verifiable-geo-fence.md (https://github.com/ramkri123/ietf-tpm-geofencing/blob/master/ draft-lkspa-wimse-verifiable-geo-fence.md). [HPE-ILO7] HPE, "HPE iLO 7 Security Whitepaper", https://www.hpe.com (https://www.hpe.com). Authors' Addresses Ramki Krishnan JPMorgan Chase Email: ramkri123@gmail.com Michael Richardson Sandelman Software Works Inc Email: mcr+IETF@sandelman.ca Diego R. Lopez Telefonica Email: diego.r.lopez@telefonica.com A Prasad Oracle Email: a.prasad@oracle.com Srinivasa Addepalli Aryaka Email: srinivasa.addepalli@aryaka.com Krishnan, et al. Expires 2 September 2026 [Page 7]