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
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | sripad karthik | ||
| Last updated | 2026-09-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hebbar-zeropath-vpn-protocol-01
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 "<ZessionId>_EPOCH_<NNN>" 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.<hostname>". 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 "<IP>:<port>" 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:<base64url-
encoded-SHA256-hash-of-public-key>". 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:<float>"), 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: <old> -> <new>"; (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, <https://www.rfc-editor.org/rfc/rfc1928>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
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, <https://github.com/sripad2020/Zeropath-vpn>.
[NIST-ZT] Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
"Zero Trust Architecture", NIST SP 800-207, August 2020,
<https://doi.org/10.6028/NIST.SP.800-207>.
[PYPI] Hebbar, S. R., "zeropath-vpn PyPI Package (v1.0.0)", 2026,
<https://pypi.org/project/zeropath-vpn/1.0.0/>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<https://www.rfc-editor.org/rfc/rfc4301>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", RFC 8996, March 2021,
<https://www.rfc-editor.org/rfc/rfc8996>.
[RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", RFC 9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9162] Laurie, B., "Certificate Transparency Version 2.0",
RFC 9162, December 2021,
<https://www.rfc-editor.org/rfc/rfc9162>.
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]