DISPATCH Working Group S. R. Hebbar Internet-Draft Independent Researcher Intended status: Standards Track September 2026 Expires: 8 March 2027 ZeroPath VPN: Hop-Bound Secure Packet Validation with State-Bound Ephemeral Sessions, Cryptographic Attestation, and Opcode-Driven Control Architecture draft-hebbar-zeropath-vpn-protocol-01 Abstract This document specifies the complete ZeroPath VPN protocol suite, comprising three coordinated sub-protocols: HBSPV (Hop-Bound Secure Packet Validation) -- a three-domain packet framing model that isolates payload decryption to the authorized egress node while allowing intermediate hops to validate forwarding context without accessing payload content. SGCP (State Graph Cryptographic Protocol) -- a three-message cryptographically attested handshake enforcing mutual authentication and device posture verification before any session is established. SCSWP (Secure Cryptographic Session Workspace Protocol) -- a continuous session state mechanism providing tamper-evident hash chain continuity, epoch-bound forward secrecy, and four-dimensional trust scoring across the full session lifetime. This document additionally specifies a complete opcode architecture governing all control-plane and data-plane message types, providing a machine-parseable, extensible message dispatch framework. The protocol suite is implemented as a pure Python reference implementation at https://github.com/sripad2020/Zeropath-vpn. 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/. Hebbar Expires 8 March 2027 [Page 1] Internet-Draft ZeroPath VPN Protocol Suite September 2026 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 5 March 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Design Philosophy . . . . . . . . . . . . . . . . . . . . 4 1.2. Relationship to Existing Protocols . . . . . . . . . . . 5 1.3. Implementation . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 3. Protocol Architecture: Six Planes . . . . . . . . . . . . . . 7 3.1. Plane Definitions . . . . . . . . . . . . . . . . . . . . 7 3.2. Plane Interaction and Phase Ordering . . . . . . . . . . 8 3.3. Port Assignments . . . . . . . . . . . . . . . . . . . . 8 4. Client Lifecycle State Machine . . . . . . . . . . . . . . . 9 4.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. SCSWP State Events Linked to Lifecycle . . . . . . . . . 9 5. Five-Stage Trust Decision Model . . . . . . . . . . . . . . . 10 6. Endpoint Capsule Structure . . . . . . . . . . . . . . . . . 10 6.1. Capsule Fields . . . . . . . . . . . . . . . . . . . . . 11 6.2. Capsule Delivery . . . . . . . . . . . . . . . . . . . . 12 6.3. Capsule Validity Window . . . . . . . . . . . . . . . . . 12 7. Dissolver Bootstrap Validator . . . . . . . . . . . . . . . . 12 7.1. Step 1 -- Credential Recognition . . . . . . . . . . . . 12 7.2. Step 2 -- Certificate / Public Key Validation . . . . . . 12 7.3. Step 3 -- Trust Anchor Selection . . . . . . . . . . . . 12 7.4. Step 4 -- Identity Binding . . . . . . . . . . . . . . . 13 7.5. Step 5 -- Endpoint Validation . . . . . . . . . . . . . . 13 7.6. Step 6 -- Server FQDN Validation . . . . . . . . . . . . 13 7.7. Step 7 -- Bootstrap Policy Validation . . . . . . . . . . 13 Hebbar Expires 8 March 2027 [Page 2] Internet-Draft ZeroPath VPN Protocol Suite September 2026 8. SGCP: Attested Handshake . . . . . . . . . . . . . . . . . . 14 8.1. Attested SYN (Client to Server) . . . . . . . . . . . . . 14 8.2. Server Eight-Step Validation Pipeline . . . . . . . . . . 15 8.3. Attested SYN-ACK (Server to Client) . . . . . . . . . . . 15 8.4. Attested ACK (Client to Server) . . . . . . . . . . . . . 15 9. SCSWP: Session State Engine . . . . . . . . . . . . . . . . . 16 9.1. K1/K2/K3 Key Hierarchy . . . . . . . . . . . . . . . . . 16 9.2. State Hash Chain . . . . . . . . . . . . . . . . . . . . 16 9.3. DNAC: Dynamic Nonce-Authenticated Chain . . . . . . . . . 16 9.4. Trust Scoring: D/N/P/S Model . . . . . . . . . . . . . . 17 10. Security Epoch System . . . . . . . . . . . . . . . . . . . . 18 10.1. Epoch Derivation . . . . . . . . . . . . . . . . . . . . 18 10.2. Epoch Rotation Triggers . . . . . . . . . . . . . . . . 18 10.3. Key Erasure Procedure . . . . . . . . . . . . . . . . . 18 11. HBSPV: Three-Domain Packet Frame . . . . . . . . . . . . . . 19 11.1. Domain 1: Outer Authenticated Forwarding Header . . . . 19 11.2. Domain 2: Protected Routing and Policy Context . . . . . 19 11.3. Domain 3: End-to-End Protected Inner Payload . . . . . . 19 11.4. Hop Validation Records . . . . . . . . . . . . . . . . . 20 11.5. Hop Processing Rules by Role . . . . . . . . . . . . . . 20 12. Opcode Architecture . . . . . . . . . . . . . . . . . . . . . 20 12.1. Opcode Encoding . . . . . . . . . . . . . . . . . . . . 20 12.2. Control Plane Opcodes . . . . . . . . . . . . . . . . . 21 12.3. Data Plane Opcodes . . . . . . . . . . . . . . . . . . . 22 12.4. State Opcodes . . . . . . . . . . . . . . . . . . . . . 22 12.5. Error Opcodes . . . . . . . . . . . . . . . . . . . . . 23 13. Authorized Path Selection . . . . . . . . . . . . . . . . . . 23 14. Data Plane: SOCKS5 Tunnel Forwarder . . . . . . . . . . . . . 24 15. Session Recovery . . . . . . . . . . . . . . . . . . . . . . 24 16. Path Migration . . . . . . . . . . . . . . . . . . . . . . . 25 17. Security Considerations . . . . . . . . . . . . . . . . . . . 25 17.1. Replay Attack Prevention . . . . . . . . . . . . . . . . 25 17.2. Forward Secrecy . . . . . . . . . . . . . . . . . . . . 25 17.3. Domain 3 Confidentiality . . . . . . . . . . . . . . . . 26 17.4. Trust Score Manipulation . . . . . . . . . . . . . . . . 26 17.5. State Hash Forgery . . . . . . . . . . . . . . . . . . . 26 17.6. Opcode Injection . . . . . . . . . . . . . . . . . . . . 26 17.7. SOCKS5 Proxy Scope . . . . . . . . . . . . . . . . . . . 26 17.8. Capsule Theft . . . . . . . . . . . . . . . . . . . . . 26 17.9. Cryptographic Primitive Recommendations . . . . . . . . 27 17.10. Session Termination and Secret Destruction . . . . . . . 27 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 18.1. Port Number Registrations . . . . . . . . . . . . . . . 27 18.2. Protocol Version String Registry . . . . . . . . . . . . 27 18.3. Opcode Registry . . . . . . . . . . . . . . . . . . . . 27 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 19.1. Normative References . . . . . . . . . . . . . . . . . . 29 19.2. Informative References . . . . . . . . . . . . . . . . . 29 Hebbar Expires 8 March 2027 [Page 3] Internet-Draft ZeroPath VPN Protocol Suite September 2026 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction The challenge of securing network sessions in a zero-trust architecture [NIST-ZT] requires satisfying several properties simultaneously: (a) Per-hop payload isolation: intermediate routing nodes MUST be able to validate forwarding context without accessing the inner payload. This is not satisfied by standard VPN tunnels, where any compromised hop can access all traffic. (b) Pre-data cryptographic attestation: no application data SHOULD flow until both parties have proven their identity and device posture through a signed, freshness-checked exchange. (c) State chain continuity: a tamper-evident record of every session operation MUST exist such that replaying, omitting, or reordering operations breaks the chain. (d) Forward secrecy at event granularity: each significant session event (activation, migration, recovery) MUST produce fresh key material with mandatory erasure of the previous key, not merely at session boundaries. (e) Continuous trust evaluation: the system MUST continuously assess device posture, network stability, protocol compliance, and session behavioral patterns, and MUST be able to suspend a session mid-flight without full teardown. (f) Machine-parseable message dispatch: all control and data plane messages MUST be identifiable by a compact, versioned opcode to support efficient parsing, extension, and interoperability. ZeroPath VPN is designed to satisfy all six properties. 1.1. Design Philosophy The protocol is designed around the principle that security properties should be enforced by the protocol structure itself, not by access control lists applied to a protocol that does not enforce them intrinsically. Hebbar Expires 8 March 2027 [Page 4] Internet-Draft ZeroPath VPN Protocol Suite September 2026 Domain 3 payload isolation (property a) is architectural: the structure of the three-domain frame ensures that an intermediate hop cannot decrypt the payload even if it is compromised, because it does not possess the egress key. State chain continuity (property c) is enforced by making every session operation produce a new hash that depends on all previous operations. There is no "skip" operation that could hide a tampered history. Forward secrecy at event granularity (property d) is enforced by requiring key erasure before the new key reference is stored. The implementation cannot complete an epoch rotation without overwriting the old key reference. 1.2. Relationship to Existing Protocols HBSPV is complementary to IPsec [RFC4301] and TLS [RFC8446]. Where TLS provides confidentiality and authentication of the channel between two endpoints, HBSPV provides per-hop authorization of forwarding decisions along a multi-hop path, without requiring each hop to terminate and re-originate TLS. Legacy TLS versions 1.0 and 1.1 MUST NOT be used [RFC8996]. SGCP's attested handshake shares goals with QUIC's connection establishment [RFC9000] but adds device attestation and an eight-step server-side validation pipeline that goes beyond certificate verification. SCSWP's state chain and DNAC mechanism share conceptual similarity with Certificate Transparency [RFC9162] logs, but operate per-session rather than globally. 1.3. Implementation A complete reference implementation [IMPL] in Python (pure standard library, zero external dependencies) is published on PyPI [PYPI] and available on GitHub at: https://github.com/sripad2020/Zeropath-vpn The implementation includes: REST control plane server, asyncio tunnel forwarder, interactive client CLI, asyncio SOCKS5 proxy, and a real-time web monitoring dashboard. Hebbar Expires 8 March 2027 [Page 5] Internet-Draft ZeroPath VPN Protocol Suite September 2026 2. Conventions and Terminology 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. HBSPV Hop-Bound Secure Packet Validation. The three-domain packet framing sub-protocol. SGCP State Graph Cryptographic Protocol. The attested handshake sub-protocol. SCSWP Secure Cryptographic Session Workspace Protocol. The session state continuity sub-protocol. Zession An ephemeral session instance. Each Zession has a unique ZessionId of the form "ZESS_<10 hex chars>". Epoch A bounded cryptographic period associated with a specific K3 key. A new Epoch is derived on each rotation trigger. The old K3 is erased when the Epoch ends. Epoch ID Identifier of the form "_EPOCH_" where NNN is a zero-padded three-digit epoch counter. Capsule An Endpoint Capsule (Section 6). A short-lived, server- signed descriptor of the server's identity, reachable endpoints, and policy reference. Dissolver The client-side bootstrap validator (Section 7) that applies seven mandatory validation steps to a Capsule. .hbspv The file extension used for the client configuration bundle. Contains the Capsule, key references, initial state hash, path profile, and policy. DNAC Dynamic Nonce-Authenticated Chain. An independent hash chain that advances in parallel with the state chain. K1 Session Root Key reference. Established at provisioning time. Never stored as raw key material. K2 Workspace Authentication Key reference. Derived from K1 with policy and path context. K3 Epoch Key reference. Derived from K1, K2, and fresh entropy. Hebbar Expires 8 March 2027 [Page 6] Internet-Draft ZeroPath VPN Protocol Suite September 2026 Rotated on every epoch boundary event. Old K3 MUST be erased before the new K3 is stored. TOFU Trust On First Use. The initial fingerprint pinning strategy used by the Dissolver when no pre-configured trust anchor exists. Opcode A 2-byte big-endian unsigned integer identifying the type of a control-plane or data-plane message. Frame An HBSPV packet comprising three security domains. ZessionId Unique session identifier. Format: "ZESS_" + 10 random uppercase hex characters. ClientId Unique client identifier. Format: "CLT_" + 10 random uppercase hex characters. PathScore A floating-point value in [0, 100] indicating the quality of an authorized path profile. TrustScore A floating-point value in [0, 100] representing the composite four-dimensional trust evaluation for a Zession. Freshness Window The maximum age of a signed message that the server will accept. RECOMMENDED: 300 seconds. 3. Protocol Architecture: Six Planes The ZeroPath VPN protocol suite is organized into six logical planes. Each plane is responsible for a distinct aspect of the protocol. 3.1. Plane Definitions +=============+==============================================+ | Plane | Responsibility | +=============+==============================================+ | Control | Session lifecycle management. Exposes a | | Plane | REST API on TCP/3000. Handles provisioning, | | | attestation, activation, migration, | | | recovery, disconnect, and status. | +-------------+----------------------------------------------+ | Bootstrap | Endpoint Capsule delivery and Dissolver- | | Plane | based validation. Clients MUST complete | | | bootstrap before entering the attestation | | | plane. | +-------------+----------------------------------------------+ | Attestation | SGCP three-message handshake. No Zession is | | Plane | established without a completed handshake. | Hebbar Expires 8 March 2027 [Page 7] Internet-Draft ZeroPath VPN Protocol Suite September 2026 +-------------+----------------------------------------------+ | State Plane | SCSWP authenticated hash chain, DNAC, K1/K2/ | | | K3 key hierarchy, and D/N/P/S trust scoring. | +-------------+----------------------------------------------+ | Path | HBSPV three-domain packet framing and hop | | Validation | validation. Each packet carries its own | | Plane | forwarding authorization. | +-------------+----------------------------------------------+ | Data Plane | SOCKS5 tunnel forwarder. Bidirectional TCP | | | forwarding on TCP/4444 with ZessionId token | | | authentication. | +-------------+----------------------------------------------+ Table 1: Six Logical Planes 3.2. Plane Interaction and Phase Ordering A client MUST complete the following phases in strict order: Phase 1 -- Bootstrap: Obtain a Capsule from the server's Control Plane. Run the Dissolver seven-step validation. Initialize the local SCSWP state mirror. Phase 2 -- Attestation: Run the SGCP three-message attested handshake. All eight server- side validation pipeline steps MUST pass. Transcript hash stored by both parties. Phase 3 -- Activation: Register the ZessionId with the server's tunnel forwarder. Receive: assigned VPN IP, EpochId, TunnelPort. First epoch rotation is triggered at this point. K3 derived and stored; K3(prev) erased. Phase 4 -- Data: Start local SOCKS5 proxy (loopback only). Route browser traffic through proxy to server forwarder. Forwarder validates ZessionId token for every connection. 3.3. Port Assignments The following default port assignments apply. All are configurable via operator parameters or environment variables. * TCP/3000 -- Control Plane REST API * TCP/4444 -- Data Plane Tunnel Forwarder Hebbar Expires 8 March 2027 [Page 8] Internet-Draft ZeroPath VPN Protocol Suite September 2026 * TCP/1080 -- Client-side SOCKS5 Proxy (loopback only) 4. Client Lifecycle State Machine Each client progresses through the following states. These states are represented by the ClientStatus enumeration in the reference implementation. 4.1. States +===============+=================================================+ | State | Meaning | +===============+=================================================+ | PROVISIONED | Client record created on server. No Capsule | | | generated yet. | +---------------+-------------------------------------------------+ | PACKAGE_READY | Capsule and client configuration bundle (.hbspv | | | file) generated and available for download. | +---------------+-------------------------------------------------+ | DOWNLOADED | Client has received the .hbspv bundle. | +---------------+-------------------------------------------------+ | ATTESTING | SGCP handshake in progress. | +---------------+-------------------------------------------------+ | CONNECTED | Handshake complete, tunnel active, HBSPV path | | | validated. | +---------------+-------------------------------------------------+ | DISCONNECTED | Transport dropped. Zession state retained. | | | Recovery possible without re-provisioning. | +---------------+-------------------------------------------------+ | RECOVERING | Section 15 session recovery underway. | +---------------+-------------------------------------------------+ | TERMINATED | Zession dissolved. All key material erased. | +---------------+-------------------------------------------------+ Table 2: Client States 4.2. SCSWP State Events Linked to Lifecycle Every lifecycle transition appends a record to the SCSWP state chain: * OP_PROVISION -- Client created. * OP_HANDSHAKE -- Attested handshake complete. * OP_ACTIVATE -- Tunnel activated. * OP_PACKET -- Each HBSPV test packet transmitted. Hebbar Expires 8 March 2027 [Page 9] Internet-Draft ZeroPath VPN Protocol Suite September 2026 * OP_MIGRATE -- Path migration completed. * OP_RECOVER -- Session recovery completed. * OP_DISCONNECT -- Tunnel disconnected. * OP_TERMINATE -- Session terminated and all keys erased. 5. Five-Stage Trust Decision Model Trust decisions in ZeroPath VPN are organized into five sequential stages. Each stage MUST be satisfied before the next stage is evaluated. Stage 1 -- IDENTITY Is the client identity recognized and valid? ClientId matches a provisioned record. Identity email format matches stored identity. Stage 2 -- DEVICE_TRUST Is the client device the one that was registered? Device reference ID matches stored device reference. Platform hash within acceptable variance. Device fingerprint change penalty applied if mismatch. Stage 3 -- ATTESTED_CONNECTION Has the SGCP handshake been completed successfully? All eight server-side validation steps passed. Ed25519 signatures verified on all three messages. Transcript hash stored and consistent. Stage 4 -- ZESSION_AUTHORIZATION Is the current Zession in a valid state for this operation? ZessionId matches. Trust score above suspension threshold (> 10.0). Session not in TERMINATED or SUSPENDED state. Stage 5 -- PATH_AUTHORIZATION + HBSPV_HOP_VALIDATION Is the requested path authorized and are packets valid? PathProfileId is in the server's authorized path set. Policy compliance flag is TRUE for chosen path. HBSPV frame epoch matches current epoch. Packet sequence number is strictly monotonically increasing. 6. Endpoint Capsule Structure The Endpoint Capsule is the server-signed descriptor that a client MUST validate through the Dissolver before connecting. It is the primary bootstrap trust anchor. Hebbar Expires 8 March 2027 [Page 10] Internet-Draft ZeroPath VPN Protocol Suite September 2026 6.1. Capsule Fields capsule_id (string, REQUIRED) A unique identifier for this specific capsule instance. Format: "CAP_" followed by random hex characters. zession_id (string, REQUIRED) The ZessionId for the session this capsule governs. server_identity (string, REQUIRED) A human-readable label identifying the server. Format: "sgcp- control.". MUST NOT be a bare IP address. server_fqdn (string, REQUIRED) The Fully Qualified Domain Name of the server. A client MUST NOT connect if this field contains a bare IP. authorized_endpoints (array of strings, REQUIRED) Each element is an ":" string. MUST contain at least one element. The client MUST NOT connect to any endpoint not in this list. transport_type (string, REQUIRED) The transport protocol. RECOMMENDED value: "TCP-ATTESTED". public_key_fingerprint (string, REQUIRED) The server's public key fingerprint. Format: "SHA256:". Length of the hash portion MUST be at least 43 characters. policy_id (string, REQUIRED) The policy template governing this Zession. RECOMMENDED values: "POL_ZERO_TRUST_STRICT", "POL_ENTERPRISE_SPLIT", "POL_CLASSIFIED". nonce (string, REQUIRED) A unique random value preventing Capsule replay. MUST be at least 128 bits of random data (32 hex characters). expiration (string, REQUIRED) ISO 8601 UTC timestamp after which the Capsule is invalid. RECOMMENDED expiry window: 300 seconds from issuance. attestation_context_reference (string, REQUIRED) A SHA256 hash reference linking this Capsule to the client's device attestation context. Used in SGCP SYN message. signed_manifest_hash (string, REQUIRED) SHA256 hash of the full client configuration bundle. Hebbar Expires 8 March 2027 [Page 11] Internet-Draft ZeroPath VPN Protocol Suite September 2026 authentication_data (string, REQUIRED) A server-computed authentication credential over the Capsule fields. 6.2. Capsule Delivery The Capsule is delivered as part of the .hbspv JSON bundle via POST /api/clients/:id/package. The entire bundle is saved to disk (default: client_config.hbspv). The Capsule is validated by the Dissolver before any connection. 6.3. Capsule Validity Window The RECOMMENDED expiration window is 300 seconds from the time of generation. This short window limits the risk of a stolen Capsule being used to impersonate the legitimate client. Implementations that require longer validity windows for operational reasons SHOULD document their threat model rationale. 7. Dissolver Bootstrap Validator The Dissolver is the client-side engine that validates the Endpoint Capsule before any connection attempt. All seven steps MUST pass. Failure at any step MUST cause the client to refuse connection and SHOULD emit a diagnostic message identifying the failing step. 7.1. Step 1 -- Credential Recognition CONDITION: The publicKeyFingerprint field MUST be present and MUST NOT be empty. ON FAILURE: Reject connection with diagnostic "Credential Recognition FAILED -- fingerprint field absent or empty." 7.2. Step 2 -- Certificate / Public Key Validation CONDITION: The publicKeyFingerprint MUST match the pattern: "SHA256:" followed by at least 32 characters. ON FAILURE: Reject with "Certificate Validation FAILED -- fingerprint format invalid." 7.3. Step 3 -- Trust Anchor Selection CONDITION: If a pinned fingerprint exists, the Capsule's publicKeyFingerprint MUST match the pinned value. If no pinned fingerprint exists, the Capsule's fingerprint is accepted and pinned (TOFU). Hebbar Expires 8 March 2027 [Page 12] Internet-Draft ZeroPath VPN Protocol Suite September 2026 ON FAILURE: Reject with "Trust Anchor FAILED -- fingerprint does not match pinned value." 7.4. Step 4 -- Identity Binding CONDITION: The serverIdentity field MUST consist of at least two components separated by a period. It MUST NOT be an IP address. ON FAILURE: Reject with "Identity Binding FAILED -- server identity malformed or bare IP." 7.5. Step 5 -- Endpoint Validation CONDITION: The authorizedEndpoints array MUST be non-empty. The client MUST only attempt connections to endpoints listed in this array. ON FAILURE: Reject with "Endpoint Validation FAILED -- no authorized endpoints." 7.6. Step 6 -- Server FQDN Validation CONDITION: The serverFQDN field MUST be present and MUST NOT be a bare IP address. ON FAILURE: Reject with "FQDN Validation FAILED -- serverFQDN absent or is a bare IP address." 7.7. Step 7 -- Bootstrap Policy Validation CONDITION: All three of the following MUST be true: (a) expiration timestamp MUST be in the future; (b) nonce field MUST be present and non-empty; (c) attestationContextReference MUST be present and non- empty. ON FAILURE (expiry): If the server is reachable, the client SHOULD automatically delete the expired Capsule, request a new one, and re- run all seven steps. ON FAILURE (nonce or attestRef absent): Reject with "Bootstrap Policy FAILED -- nonce or attestationRef missing." Hebbar Expires 8 March 2027 [Page 13] Internet-Draft ZeroPath VPN Protocol Suite September 2026 8. SGCP: Attested Handshake The SGCP attested handshake is a three-message exchange that MUST complete before any Zession is considered established. It provides mutual authentication, device posture verification, nonce-based replay protection, timestamp freshness enforcement, an eight-step server-side validation pipeline, and transcript binding. 8.1. Attested SYN (Client to Server) The client builds the Attested SYN using the SGCPEngine. Fields include: client_id (string, REQUIRED) The client's identity string (email format preferred). device_identity_reference (string, REQUIRED) An opaque reference to the client's device identity record (DeviceRefId). device_context_reference (string, REQUIRED) SHA256(platform description string). Allows the server to detect device changes. client_nonce (string, REQUIRED) A 128-bit (32 hex character) cryptographically random value. MUST be unique across all sessions. timestamp (string, REQUIRED) ISO 8601 UTC timestamp. MUST be within the Freshness Window (RECOMMENDED: 300 seconds). connection_context (string, REQUIRED) SHA256("CONN_CTX:" + clientId + ":" + zessionId + ":" + unix_timestamp_float). protocol_version (string, REQUIRED) "HBSPV/2.0-SGCP/2.0" attestation_context (string, REQUIRED) The attestationContextReference from the Endpoint Capsule. digital_signature (string, REQUIRED) Ed25519 signature over pipe-delimited concatenation of all above fields. Format: "SIG_ED25519:<32-hex-chars>". Hebbar Expires 8 March 2027 [Page 14] Internet-Draft ZeroPath VPN Protocol Suite September 2026 8.2. Server Eight-Step Validation Pipeline Upon receipt of the Attested SYN, the server MUST execute all eight steps in sequence. Failure at any step MUST terminate the handshake. 1. Parse Attestation Context: verify all required fields are present and well-formed. 2. Client ID Lookup: match client_id to the provisioned client record. Stored identity MUST exactly match. 3. Certificate Check: verify client's publicKeyFingerprint is present and in correct format. 4. Digital Signature Verification: reconstruct the signature payload and verify using client's stored public key reference with constant-time comparison. 5. Device Context Check: verify device_identity_reference matches stored device reference. 6. Nonce Validation and Replay Protection: if client_nonce already seen, MUST reject. If fresh, add to used-nonce set. 7. Timestamp Freshness Check: reject if |current_UTC - syn.timestamp| > 300 seconds. 8. Policy Evaluation: verify client's assigned policy allows the requested connection context. 8.3. Attested SYN-ACK (Server to Client) If all eight steps pass, the server constructs the Attested SYN-ACK containing: server_identity, server_certificate_reference, client_nonce_reference (echo of SYN nonce), server_nonce (fresh 128-bit random), timestamp, connection_context, attestation_context, digital_signature, and validation_pipeline (array of all eight step results). 8.4. Attested ACK (Client to Server) The client verifies the SYN-ACK server signature, then builds the Attested ACK containing a transcript proof: transcript_reference = SHA256(syn.client_nonce | syn_ack.server_nonce | syn.connection_context | client_identity) Hebbar Expires 8 March 2027 [Page 15] Internet-Draft ZeroPath VPN Protocol Suite September 2026 This hash binds the ACK irrevocably to the specific three-way exchange. On success, AttestState transitions to HANDSHAKE_COMPLETE and the transcript_hash is stored. On failure, the Zession is NOT established and the client MUST delete the local Capsule and re- provision. 9. SCSWP: Session State Engine The SCSWP state engine maintains three parallel structures for each Zession: a K1/K2/K3 key hierarchy, a state hash chain, and a DNAC (Dynamic Nonce-Authenticated Chain). 9.1. K1/K2/K3 Key Hierarchy K1 (Session Root Key): K1 = SHA256("K1:" + zessionId + ":" + sessionRootContext)[:16] + "...". Established once at provisioning time. Does not rotate within the Zession lifetime. K2 (Workspace Authentication Key): K2 = SHA256("K2:" + K1_ref + ":" + policyId + ":" + pathId)[:16] + "...". MUST be re-derived if the policy or authorized path profile changes. K3 (Epoch Key): fresh_nonce = random 128-bit value; K3 = SHA256("K3:" + K1_ref + ":" + K2_ref + ":EPOCH_" + epoch_counter + ":" + fresh_nonce)[:16] + "...". Derived fresh on each epoch rotation. When K3 is rotated, the previous K3 reference MUST be overwritten in storage before the new K3 reference is written. Production implementations MUST also erase the raw key material and zero the memory before overwriting. 9.2. State Hash Chain Initial state: state_hash(0) = SHA256("INIT:" + zessionId + ":" + timestamp) Subsequent states: state_hash(N) = SHA256(state_hash(N-1) + ":" + sequence_number + ":" + event_description + ":" + ISO8601_timestamp) Every Zession operation appends a new ScswpStateRecord to the chain. The chain is cryptographically linked; each record depends on all previous records. 9.3. DNAC: Dynamic Nonce-Authenticated Chain The DNAC is a second, independent hash chain that advances in parallel with the state chain. Hebbar Expires 8 March 2027 [Page 16] Internet-Draft ZeroPath VPN Protocol Suite September 2026 Initialization: dnac(0) = "GENESIS" Advancement: dnac(N) = SHA256(dnac(N-1) + ":" + zessionId + ":" + operationId + ":" + workspaceState + ":" + ISO8601_timestamp) Session recovery (Section 15) MUST validate both the state hash and the DNAC value before resuming. An implementation MUST NOT allow recovery that resets the DNAC chain to a previous value. 9.4. Trust Scoring: D/N/P/S Model The trust score is a floating-point value in [0.0, 100.0] evaluated on every session operation across four dimensions: * D -- Device Trust: device characteristics vs. those at session establishment. * N -- Network Trust: IP address stability. A change triggers PENALTY_NETWORK_CHANGE (-15.0). * P -- Protocol Trust: nonce freshness, timestamp validity, signature correctness, protocol version match. * S -- Session Trust: operation rate and sequence number monotonicity. Rapid operations (>20/10s) trigger PENALTY_RAPID_OPS (-5.0). +==============================+=======+========================+ | Event | Delta | Constant | +==============================+=======+========================+ | Network IP change | -15.0 | PENALTY_NETWORK_CHANGE | +------------------------------+-------+------------------------+ | Device fingerprint change | -60.0 | PENALTY_DEVICE_CHANGE | +------------------------------+-------+------------------------+ | Rapid operations (>20/10s) | -5.0 | PENALTY_RAPID_OPS | +------------------------------+-------+------------------------+ | Authentication failure | -25.0 | PENALTY_AUTH_FAIL | +------------------------------+-------+------------------------+ | Stable operation (no issues) | +0.5 | REWARD_STABLE_TRUST | +------------------------------+-------+------------------------+ Table 3: Trust Score Penalty and Reward Constants If trust_score <= TRUST_SUSPENSION (10.0): is_suspended = True; the server MUST refuse further requests. Hebbar Expires 8 March 2027 [Page 17] Internet-Draft ZeroPath VPN Protocol Suite September 2026 10. Security Epoch System The Security Epoch System binds cryptographic key material to the authenticated session state. An epoch cannot be constructed without the current SCSWP state hash. 10.1. Epoch Derivation EpochId = ZessionId + "_EPOCH_" + zero_padded_epoch_number (e.g., "ZESS_A3B5C7D9E1_EPOCH_000"). state_bound_hash = SHA256(prev_state_hash + ":" + fresh_entropy + ":" + session_transcript_ref + ":" + authorized_path_context) fresh_entropy MUST be at least 128 bits of cryptographically random data generated fresh for each epoch. 10.2. Epoch Rotation Triggers An epoch MUST rotate on any of the following events: * TRIGGER_ACTIVATION: client completes Phase 3 (tunnel activation). * TRIGGER_MIGRATION: client migrates to a different authorized path profile. * TRIGGER_RECOVERY: session recovery (Section 15) completes. * TRIGGER_SCHEDULED: rekey interval elapsed (RECOMMENDED: 1800 seconds). 10.3. Key Erasure Procedure The following procedure MUST be executed on each epoch rotation: 1. Derive the new K3 reference from K1, K2, and fresh_entropy for the new epoch. 2. Store the new K3 reference in a temporary variable. 3. Overwrite the storage location of the old K3 reference with the new K3 reference value. 4. Zero the temporary variable. 5. Increment the epoch sequence number. Hebbar Expires 8 March 2027 [Page 18] Internet-Draft ZeroPath VPN Protocol Suite September 2026 6. Add an OP_ACTIVATE, OP_MIGRATE, or OP_RECOVER record to the SCSWP state chain, referencing the new EpochId. In production systems, Step 3 MUST use a memory barrier to prevent compiler or CPU reordering of the zero-write. 11. HBSPV: Three-Domain Packet Frame HBSPV defines a packet frame comprising three security domains. The architectural guarantee: "An intermediate authorized hop can validate all information it needs to make a forwarding decision without possessing the key material needed to decrypt the inner payload." 11.1. Domain 1: Outer Authenticated Forwarding Header Domain 1 is visible to and processable by ALL authorized hops. Key fields include: protocolVersion, compactZessionReference, packetSequenceNumber (monotonically increasing 64-bit, starting at 10001), securityEpochReference, currentHopReference, nextHopReference, validationStateReference, pathContextReference, attestationContextReference, deviceContextReference, and outerAuthTag (HMAC-SHA256(K2_ref, sequence_number + ":" + epochId)[:16]). All hops MUST verify the outerAuthTag. Hops MUST reject packets whose epoch reference does not match the currently expected epoch. Hops MUST reject any packet with a sequence number <= the last accepted value. 11.2. Domain 2: Protected Routing and Policy Context Domain 2 carries routing authorization evidence. Fields include: pathAuthorizationReference (full PathProfileId), policyReference, trustContextReference ("TRUST_SCORE:"), routeConstraints (array: "NO_UNAUTHENTICATED_HOPS", "STRICT_EPOCH_MATCH", "STRICT_EGRESS_MATCH"), and routingAuthEvidence (Ed25519 signature over Domain 1 + Domain 2 fields). 11.3. Domain 3: End-to-End Protected Inner Payload Domain 3 carries the actual application payload, encrypted such that ONLY the authorized egress gateway can decrypt it. Fields include: decryptionStatusAtIntermediateHops ("PROTECTED_CIPHERTEXT -- NOT DECRYPTED AT INTERMEDIATE HOPS"), targetDestination, innerProtocol, encryptedPayloadHex (AES-256-GCM ciphertext), and innerPayloadIntegrityTag (POLY1305 authentication tag). Hebbar Expires 8 March 2027 [Page 19] Internet-Draft ZeroPath VPN Protocol Suite September 2026 11.4. Hop Validation Records Each hop that processes an HBSPV frame appends a HopRecord to the frame's hop_validation_chain. Fields: hop_id, zession_reference, packet_sequence_reference, security_epoch, path_context_reference, validation_result ("HOP_VALIDATED", "FINAL_VALIDATED", or "REJECTED"), freshness_context, authenticated_validation_evidence, and inner_payload_decrypted (boolean, MUST be False at all hops except the authorized egress). 11.5. Hop Processing Rules by Role Entry Gateway: MUST validate Domain 1 outerAuthTag, epoch, sequence number, Domain 2 routeConstraints and routingAuthEvidence. MUST NOT attempt to decrypt Domain 3. MUST set HopRecord.inner_payload_decrypted = False. Infrastructure Hop: MUST validate Domain 1 outerAuthTag and epoch. MUST NOT access Domain 2 or Domain 3 or modify any domain. Egress Gateway: MUST validate all Domain 1 and Domain 2 fields including "STRICT_EGRESS_MATCH". MUST decrypt Domain 3 using the Zession's egress key (K3-derived) and verify innerPayloadIntegrityTag before forwarding plaintext. MUST set HopRecord.inner_payload_decrypted = True and HopRecord.validation_result = "FINAL_VALIDATED". 12. Opcode Architecture The opcode architecture provides a compact, versioned, machine- parseable identifier for every message type exchanged in the ZeroPath VPN protocol suite. 12.1. Opcode Encoding Each message MUST begin with a 16-byte Opcode Header: Hebbar Expires 8 March 2027 [Page 20] Internet-Draft ZeroPath VPN Protocol Suite September 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode (16 bits) | Version (8 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags (8 bits) | Payload Length (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length continued (MSB to LSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (variable, JSON encoded) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags bits: Bit 7 (ENCRYPTED), Bit 6 (SIGNED), Bit 5 (FRAGMENTED), Bit 4 (LAST_FRAG). Bits 3-0 Reserved, MUST be zero. Version 0x02 corresponds to "HBSPV/2.0-SGCP/2.0". +===============+===============================================+ | Range | Category | +===============+===============================================+ | 0x0001-0x00FF | Control Plane: Lifecycle Opcodes | +---------------+-----------------------------------------------+ | 0x0100-0x01FF | Control Plane: Session Management Opcodes | +---------------+-----------------------------------------------+ | 0x0200-0x02FF | Control Plane: Bootstrap Opcodes | +---------------+-----------------------------------------------+ | 0x0300-0x03FF | Data Plane: Tunnel Opcodes | +---------------+-----------------------------------------------+ | 0x0400-0x04FF | State Opcodes | +---------------+-----------------------------------------------+ | 0x0500-0x05FF | Error Opcodes | +---------------+-----------------------------------------------+ | 0x0600-0xEFFF | Reserved for future use | +---------------+-----------------------------------------------+ | 0xF000-0xFFFF | Vendor/Experimental. Not to be standardized. | +---------------+-----------------------------------------------+ Table 4: Opcode Ranges 12.2. Control Plane Opcodes 0x0001 OP_PROVISION_REQUEST (C->S): Request provisioning. Payload: identity, department, device_name, platform, policy_id. 0x0002 OP_PROVISION_RESPONSE (S->C): Return client_id and zession_id. 0x0003 OP_PACKAGE_REQUEST (C->S): Request .hbspv bundle download. Hebbar Expires 8 March 2027 [Page 21] Internet-Draft ZeroPath VPN Protocol Suite September 2026 0x0004 OP_PACKAGE_RESPONSE (S->C, ENCRYPTED|SIGNED): Deliver complete .hbspv client configuration bundle. 0x0005 OP_ATTEST_SYN (C->S, SIGNED): Carry the Attested SYN (Section 8.1). 0x0006 OP_ATTEST_SYNACK (S->C, SIGNED): Carry the Attested SYN-ACK and pipeline results (Section 8.3). 0x0007 OP_ATTEST_ACK (C->S, SIGNED): Carry the Attested ACK with transcript proof (Section 8.4). 0x0008 OP_ATTEST_COMPLETE (S->C): Confirm handshake completion. Payload: status, transcript_hash, validation_pipeline. 0x0009 OP_ACTIVATE_REQUEST (C->S, SIGNED): Request tunnel activation. 0x000A OP_ACTIVATE_RESPONSE (S->C, ENCRYPTED): Confirm activation; deliver assigned_ip, epoch_id, tunnel_port, trust_score, state_hash. 0x000B OP_DISCONNECT_REQUEST (C->S): Signal voluntary disconnection. 0x000C OP_DISCONNECT_RESPONSE (S->C): Confirm disconnection with final state_hash and epoch_id. 12.3. Data Plane Opcodes 0x0300 OP_TUNNEL_CONNECT (C->S): Initiate tunneled connection. Wire: 4-byte big-endian length prefix + JSON payload: {type, host, port, token (ZessionId)}. 0x0301 OP_TUNNEL_CONNECT_ACK (S->C): Confirm connection success. After this opcode, both sides enter raw TCP forwarding mode. 0x0302 OP_TUNNEL_UNAUTHORIZED (S->C): Reject tunnel connection. Server MUST close TCP connection immediately after sending. 0x0303 OP_TUNNEL_DATA (bidirectional, ENCRYPTED|SIGNED): Carry HBSPV- framed application data. Defined for future per-packet framing implementations. 0x0304 OP_TUNNEL_CLOSE (bidirectional): Signal graceful tunnel teardown. Reason: "CLIENT_CLOSE", "SERVER_CLOSE", or "TIMEOUT". 12.4. State Opcodes 0x0400 OP_MIGRATE_REQUEST (C->S, SIGNED): Request migration to different path profile. Hebbar Expires 8 March 2027 [Page 22] Internet-Draft ZeroPath VPN Protocol Suite September 2026 0x0401 OP_MIGRATE_RESPONSE (S->C, ENCRYPTED): Confirm migration; deliver new epoch_id, state_hash, trust_score, path_profile. 0x0402 OP_RECOVER_REQUEST (C->S, SIGNED): Request session recovery. Payload includes current_state_hash for server-side validation. 0x0403 OP_RECOVER_RESPONSE (S->C, ENCRYPTED): Confirm recovery; deliver recovered_epoch, state_hash, trust_score=100. 0x0404 OP_EPOCH_ROTATE (S->C, ENCRYPTED|SIGNED): Notify client of scheduled epoch rotation. 0x0405 OP_STATUS_REQUEST (C->S): Request current session status. 0x0406 OP_STATUS_RESPONSE (S->C): Return full session status including trust_score, epoch_id, state_hash, dnac_length, capabilities. 12.5. Error Opcodes 0x0500 OP_ERROR_GENERIC (S->C): General error response. Payload: error_code, error_message, opcode_ref. 0x0501 OP_ERROR_AUTH_FAIL (S->C): Authentication or signature verification failure. Payload: step, trust_score (after PENALTY_AUTH_FAIL), detail. 0x0502 OP_ERROR_REPLAY (S->C): Nonce replay or sequence number violation. Payload: replay_type ("NONCE_REPLAY" or "SEQ_REPLAY"), rejected_nonce, expected_seq, received_seq. 0x0503 OP_ERROR_CAPSULE_EXPIRED (S->C or local Dissolver): Capsule expiry notification. Payload: expired_at, capsule_id, action ("AUTO_REPROVISION" if applicable). 0x0504 OP_ERROR_TRUST_SUSPENDED (S->C): Session suspended due to trust score collapse. Payload: trust_score (<= 10.0), suspension_at, reason. 0x0505 OP_ERROR_EPOCH_MISMATCH (hop to sending node): Epoch mismatch detected in HBSPV frame. Payload: expected_epoch, received_epoch, hop_id. 13. Authorized Path Selection A client MUST only use paths that appear in its provisioned PathProfile and that satisfy all three conditions: Authorized, Reachable, and Policy-Compliant. Hebbar Expires 8 March 2027 [Page 23] Internet-Draft ZeroPath VPN Protocol Suite September 2026 A path is authorized if: (a) the PathProfileId appears in the server's known path profiles; (b) policy_compliant == True for the client's assigned policy; (c) the path score is above the policy's minimum path score. Unauthorized path selection MUST be rejected by the server at migration time and by the egress at packet validation time. Each PathProfile contains: profile_id, name, ordered hops array (each hop with hop_id, ip, role, region, validation_status), path_score ([0.0, 100.0]), latency_ms, loss_rate, gateway_load, trust_level, and policy_compliant (boolean). 14. Data Plane: SOCKS5 Tunnel Forwarder The data plane uses an extended SOCKS5 protocol [RFC1928] with a ZessionId-based authentication handshake. The client SOCKS5 proxy MUST listen on 127.0.0.1 (IPv4 loopback only). MUST NOT listen on 0.0.0.0 or any non-loopback interface. When a browser sends a SOCKS5 CONNECT with a domain name target (ATYP=0x03), the proxy MUST forward the domain name in the "host" field of OP_TUNNEL_CONNECT without resolving it locally. The forwarder resolves the domain on the server side, preventing DNS leaks to the client's local resolver or ISP. The tunnel handshake uses 4-byte big-endian length-prefixed JSON framing. After the server sends OP_TUNNEL_CONNECT_ACK, both parties enter raw TCP forwarding mode. The server forwarder maintains an in-memory set of active ZessionIds. Token validation MUST use a constant-time comparison to prevent timing-based token enumeration. A ZessionId is removed from this set when the session is disconnected, revoked by an operator, or suspended due to trust score collapse. 15. Session Recovery Session recovery allows a client to resume a disconnected Zession without re-provisioning. The following invariants MUST be maintained: * Invariant 1 (State Continuity): client's SCSWP state hash MUST match the server's stored state hash before recovery is permitted. * Invariant 2 (No Key Reuse): recovery MUST derive a new K3 using fresh entropy. Old K3 MUST be erased before new K3 is stored. Hebbar Expires 8 March 2027 [Page 24] Internet-Draft ZeroPath VPN Protocol Suite September 2026 * Invariant 3 (DNAC Continuity): DNAC chain MUST advance on recovery. An implementation MUST NOT allow recovery that resets the DNAC chain to a previous value. Recovery procedure (7 steps): (1) client sends OP_RECOVER_REQUEST with current_state_hash; (2) server validates state hash with constant-time comparison; (3) server derives new K3 and epoch; (4) server advances SCSWP state chain; (5) server returns OP_RECOVER_RESPONSE; (6) server resets trust score to 100.0; (7) client stores new epoch ID and state hash and may re-activate the tunnel. 16. Path Migration Path migration allows a CONNECTED client to switch to a different authorized path profile without re-attesting or re-provisioning. Migration triggers a mandatory epoch rotation. Migration procedure (6 steps): (1) client sends OP_MIGRATE_REQUEST with target PathProfileId; (2) server validates authorization (profile exists, policy_compliant == True, trust score above TRUST_SUSPENSION); (3) server rotates K3 and epoch with trigger "Path Migration: -> "; (4) server updates session state (OP_MIGRATE record, DNAC advance); (5) server returns OP_MIGRATE_RESPONSE; (6) client stores new epoch ID, state hash, and updates active path profile. Client MUST NOT use old epoch for any further packets. 17. Security Considerations 17.1. Replay Attack Prevention Client nonces are tracked in a per-ZessionId used-nonce set persisting for the lifetime of the Zession. In production deployments, this set MUST be persisted to durable storage to survive server restarts. Packet sequence numbers provide replay protection at the data plane; hops MUST reject any packet with a sequence number <= the last accepted value. 17.2. Forward Secrecy Forward secrecy is provided at epoch granularity. Compromise of the current K3 does not expose traffic encrypted under previous K3 values, provided that erasure was correctly performed. Each K3 incorporates fresh entropy not present in previous derivations. Production implementations SHOULD use HKDF [RFC5869] with os.urandom() as the entropy source. Hebbar Expires 8 March 2027 [Page 25] Internet-Draft ZeroPath VPN Protocol Suite September 2026 17.3. Domain 3 Confidentiality The Domain 3 payload isolation guarantee holds under the following assumptions: (a) the egress decryption key is not shared with intermediate hops; (b) intermediate hop implementations do not attempt to buffer and decrypt Domain 3 out-of-band; (c) the AES- 256-GCM implementation is correct. Production deployments MUST place entry gateways, infrastructure hops, and egress gateways on separate, isolated physical or virtual hosts. 17.4. Trust Score Manipulation An adversary may attempt to inflate the trust score by flooding stable operations. The maximum score is capped at 100.0. A more practical attack is to force session suspension by triggering rapid operations or network changes. Implementations SHOULD rate-limit external inputs that could trigger penalties. 17.5. State Hash Forgery The state hash chain uses SHA256, which is currently collision- resistant. Implementations SHOULD monitor for future weaknesses and plan migration to SHA3-256 if collision attacks emerge. 17.6. Opcode Injection The control plane REST API MUST be protected by TLS in production. All API endpoints MUST require ZessionId or ClientId validation. In environments without TLS, an attacker on the same network could inject crafted opcodes. 17.7. SOCKS5 Proxy Scope The SOCKS5 proxy MUST bind only to 127.0.0.1. Binding to 0.0.0.0 or a non-loopback interface would allow other hosts to use the proxy without authentication. On Windows, implementations MUST use the explicit IP address string "127.0.0.1" when binding to avoid IPv6 ambiguity with "localhost". 17.8. Capsule Theft A stolen Capsule cannot complete a handshake from a different device because: (a) Step 5 (Device Context Check) will fail if the device reference does not match; and (b) Step 4 (Signature Verification) will fail because the attacker does not have the client's private key. The 300-second expiry window limits the window of opportunity. Hebbar Expires 8 March 2027 [Page 26] Internet-Draft ZeroPath VPN Protocol Suite September 2026 17.9. Cryptographic Primitive Recommendations Production implementations MUST: use real Ed25519 [RFC8032] for all digital signatures; use AES-256-GCM for Domain 3 encryption; use HKDF [RFC5869] for all key derivations; use a CSPRNG (os.urandom()) for all random value generation; use constant-time comparison (hmac.compare_digest) for all cryptographic value comparisons. 17.10. Session Termination and Secret Destruction When a Zession is terminated, the implementation MUST: erase K3, K2, and K1 references; zero the state hash buffer; remove the ZessionId from the active session token set. Only ArchivedEpoch records (without key material) are retained for audit purposes. 18. IANA Considerations 18.1. Port Number Registrations This document requests registration of the following TCP port numbers in the IANA Service Name and Transport Protocol Port Number Registry: +=================+======+===========+============================+ | Service Name | Port | Transport | Description | +=================+======+===========+============================+ | zeropath-ctrl | 3000 | TCP | ZeroPath VPN Control Plane | | | | | REST API (HBSPV/SGCP) | +-----------------+------+-----------+----------------------------+ | zeropath-tunnel | 4444 | TCP | ZeroPath VPN Data Plane | | | | | Tunnel Forwarder (HBSPV) | +-----------------+------+-----------+----------------------------+ Table 5: Port Registration Requests 18.2. Protocol Version String Registry This document requests creation of a new IANA registry "ZeroPath VPN Protocol Version Strings". Initial registration: HBSPV/2.0-SGCP/2.0 -- ZeroPath VPN version 2.0 -- This document. 18.3. Opcode Registry This document requests creation of a new IANA registry "ZeroPath VPN Opcode Registry". Policy: Specification Required for range 0x0001-0xEFFF. First Come First Served for range 0xF000-0xFFFF. Hebbar Expires 8 March 2027 [Page 27] Internet-Draft ZeroPath VPN Protocol Suite September 2026 +========+==========================+==============+ | Value | Name | Section | +========+==========================+==============+ | 0x0001 | OP_PROVISION_REQUEST | Section 12.2 | +--------+--------------------------+--------------+ | 0x0002 | OP_PROVISION_RESPONSE | Section 12.2 | +--------+--------------------------+--------------+ | 0x0003 | OP_PACKAGE_REQUEST | Section 12.2 | +--------+--------------------------+--------------+ | 0x0004 | OP_PACKAGE_RESPONSE | Section 12.2 | +--------+--------------------------+--------------+ | 0x0005 | OP_ATTEST_SYN | Section 12.2 | +--------+--------------------------+--------------+ | 0x0006 | OP_ATTEST_SYNACK | Section 12.2 | +--------+--------------------------+--------------+ | 0x0007 | OP_ATTEST_ACK | Section 12.2 | +--------+--------------------------+--------------+ | 0x0008 | OP_ATTEST_COMPLETE | Section 12.2 | +--------+--------------------------+--------------+ | 0x0009 | OP_ACTIVATE_REQUEST | Section 12.2 | +--------+--------------------------+--------------+ | 0x000A | OP_ACTIVATE_RESPONSE | Section 12.2 | +--------+--------------------------+--------------+ | 0x000B | OP_DISCONNECT_REQUEST | Section 12.2 | +--------+--------------------------+--------------+ | 0x000C | OP_DISCONNECT_RESPONSE | Section 12.2 | +--------+--------------------------+--------------+ | 0x0300 | OP_TUNNEL_CONNECT | Section 12.3 | +--------+--------------------------+--------------+ | 0x0301 | OP_TUNNEL_CONNECT_ACK | Section 12.3 | +--------+--------------------------+--------------+ | 0x0302 | OP_TUNNEL_UNAUTHORIZED | Section 12.3 | +--------+--------------------------+--------------+ | 0x0303 | OP_TUNNEL_DATA | Section 12.3 | +--------+--------------------------+--------------+ | 0x0304 | OP_TUNNEL_CLOSE | Section 12.3 | +--------+--------------------------+--------------+ | 0x0400 | OP_MIGRATE_REQUEST | Section 12.4 | +--------+--------------------------+--------------+ | 0x0401 | OP_MIGRATE_RESPONSE | Section 12.4 | +--------+--------------------------+--------------+ | 0x0402 | OP_RECOVER_REQUEST | Section 12.4 | +--------+--------------------------+--------------+ | 0x0403 | OP_RECOVER_RESPONSE | Section 12.4 | +--------+--------------------------+--------------+ | 0x0404 | OP_EPOCH_ROTATE | Section 12.4 | +--------+--------------------------+--------------+ | 0x0405 | OP_STATUS_REQUEST | Section 12.4 | Hebbar Expires 8 March 2027 [Page 28] Internet-Draft ZeroPath VPN Protocol Suite September 2026 +--------+--------------------------+--------------+ | 0x0406 | OP_STATUS_RESPONSE | Section 12.4 | +--------+--------------------------+--------------+ | 0x0500 | OP_ERROR_GENERIC | Section 12.5 | +--------+--------------------------+--------------+ | 0x0501 | OP_ERROR_AUTH_FAIL | Section 12.5 | +--------+--------------------------+--------------+ | 0x0502 | OP_ERROR_REPLAY | Section 12.5 | +--------+--------------------------+--------------+ | 0x0503 | OP_ERROR_CAPSULE_EXPIRED | Section 12.5 | +--------+--------------------------+--------------+ | 0x0504 | OP_ERROR_TRUST_SUSPENDED | Section 12.5 | +--------+--------------------------+--------------+ | 0x0505 | OP_ERROR_EPOCH_MISMATCH | Section 12.5 | +--------+--------------------------+--------------+ Table 6: Initial Opcode Registry 19. References 19.1. Normative References [RFC1928] Leech, M., "SOCKS Protocol Version 5", RFC 1928, March 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . 19.2. Informative References Hebbar Expires 8 March 2027 [Page 29] Internet-Draft ZeroPath VPN Protocol Suite September 2026 [IMPL] Hebbar, S. R., "ZeroPath VPN Reference Implementation", 2026, . [NIST-ZT] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST SP 800-207, August 2020, . [PYPI] Hebbar, S. R., "zeropath-vpn PyPI Package (v1.0.0)", 2026, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, . [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", RFC 8996, March 2021, . [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021, . [RFC9162] Laurie, B., "Certificate Transparency Version 2.0", RFC 9162, December 2021, . Acknowledgements The author thanks the open-source Python community and the IETF community for providing the standards and tools on which this work is built. Author's Address Sripad Rama Hebbar Independent Researcher India Email: sripadkarthik@gmail.com URI: https://github.com/sripad2020/Zeropath-vpn Hebbar Expires 8 March 2027 [Page 30]