UZP: Universal Zero-Port Transport Protocol

2.1. 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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terminology from UZPIF ([UZPIF]) and related work:¶

• Endpoint (EP): A host participating in UZP communication. EPs never listen on public IP:port tuples.¶

• Rendezvous Node (RN): A relay and coordination node that accepts outbound connections from EPs, validates Pantheon credentials and Grant artefacts under policy, and stitches identity-bound flows. An RN is not by itself an issuer of identity, Grant, or revocation truth.¶

• Pantheon: A federated or deployment-scoped identity, attestation, and policy plane used by UZPIF ([UZPIF]) and UZP that binds identity, policy, and trust metadata to keys or selectors accepted under local policy, may validate or certify those bindings, and may issue credentials, Grants, and delegations over them.¶

• Canonical Identity (CID): A long-lived, cryptographic identifier derived from a principal's public signing key.¶

• Ephemeral Identity (EID): A per-session identity bound to short-lived key material.¶

• Block: The semantic unit of reliability (acknowledgement / retransmission) in UZP.¶

• Frame: The semantic unit of application payload mapping inside a block; this draft does not yet assign a final wire encoding to frame types.¶

• Proof-of-Reachability (PoR): An RN-relayed authenticated liveness proof in which a peer returns profile-defined proof material bound to identity, nonce, RN context, expiry, and session context; see Section 12.¶

4.1. High-Level Session Flow

EP_I (Initiator)        RN        EP_R (Responder)
     |-- outbound ctl/data -->|              |
     |                        |<-- outbound ctl/data --|
     |<==== E2E AEAD over ZPIT (via RN) ====>|

This figure shows both endpoints initiating outbound sessions to the RN, which stitches them into a ZPIT.¶

4.2. Session State Model

For interoperable transport behaviour, endpoints MUST model each UZP association using the following baseline states:¶

new

No RN attachment, authenticated peer state, or accepted continuity state has yet been established.¶

pending

RN attachment, Join processing, or handshake evaluation is in progress. Application data other than explicitly permitted early data under Section 9 MUST NOT be released in this state.¶

authenticated

Peer identity, Grant state, and handshake bindings have been accepted, but the association is not yet in normal stitched data transfer.¶

stitched

The RN has completed the authorised stitch and the endpoints may exchange normal AEAD-protected application traffic within the accepted Grant scope.¶

failover / rebind

Continuity is being re-established at the same RN or at an alternate eligible RN. Endpoints MAY use bounded continuity state only as allowed by the failover rules in this document; any authority expansion requires fresh validation, and no RN-local claim alone is sufficient to return the association to "stitched".¶

closed

The association is terminated or abandoned. Further traffic under that session context MUST be rejected unless a separate resumption or re-enrolment mechanism explicitly authorises a new session.¶

Endpoints MUST begin in "new", MUST pass through "pending" before accepting authenticated state, MUST NOT treat "stitched" continuity as proof of continuing authorisation without the checks required by this document, and MUST treat transition into "failover / rebind" as an availability event rather than as automatic trust continuity. Loss of RN attachment changes rendezvous state; it does not by itself revoke externally verifiable identity, Grant, or revocation truth.¶

4.3. HIL-Brokered Sessions

Where legacy applications or non-native hardware cannot participate directly in UZP, a Hardware Integration Layer (HIL) as described by UZPIF ([UZPIF]) MAY establish or broker the UZP session on their behalf. In such cases, the HIL is the policy-bound compatibility boundary and the attached legacy system is not automatically a native UZP endpoint.¶

A HIL-brokered session MUST bind transport accountability to the authenticated HIL identity and MAY also carry an auditable device, slot, or port identifier for the attached legacy system when deployment policy requires that distinction. Grants and any translated session context MUST be scoped so that the HIL cannot silently generalise the authority of the attached system beyond the mediation policy under which it operates.¶

RN participation in a UZP session, whether native or HIL-brokered, MUST NOT be treated as RN authority over end-to-end identity or authentication truth. The RN may relay flights, validate locally relevant Grant constraints, and enforce forwarding policy, but the authenticated truth of the session remains bound to the cryptographic endpoint or designated HIL endpoint, the handshake transcript, and the applicable Grant state rather than to RN observation of traffic or path position.¶

4.4. Identity Model and CID Stability

Pantheon authorities bind a principal's long-term public signing key to identity, policy, and trust metadata; the canonical identity CID is defined as a hash (e.g., BLAKE3) of that public signing key. CIDs are intended to be stable over multi-year time scales and across multiple devices in the same administrative entity, and SHOULD only change when the underlying key is rotated or revoked due to compromise.¶

Deployments MAY use locally generated or externally attested keys if Pantheon policy allows; Pantheon authorities validate or certify those bindings and are not required to generate or custody the corresponding private keys.¶

Each transport session also has an Ephemeral Identity (EID), derived from short-lived key material. EIDs are bound to CIDs via Pantheon credentials over that ephemeral key material and are used within the UZP handshake and record layer.¶

This separation mirrors the long-term vs. ephemeral key split in both HIP [RFC7401] and TLS 1.3 [RFC8446].¶

5.1. Specification Boundary

This revision defines UZP message semantics, session-state logic, handshake roles, cryptographic bindings, replay constraints, PoR semantics, RN behaviour, and related transport security semantics needed for semantic interoperability.¶

Exact byte-level encoding is not yet fixed in this revision. Packet layouts, message serialisations, some transport profiling, registry completeness, retransmission and congestion profiles, PMTU or fragmentation handling, and related deployment-specific choices remain deferred or profile-defined.¶

Figures and message labels in this document are therefore illustrative. They describe message purpose and sequencing, not a completed interoperable wire format.¶

5.2. Flight Diagram

Figure Figure 2 sketches a representative two-party handshake mediated by an RN. The message labels are illustrative and show role and sequencing rather than a final byte-level wire format.¶

EP_I (Init)           RN                EP_R (Resp)
 |--[1] CH1: CH_I, EID_I, Grant ------->|                    |
 |                 |--[2] CH1' (fwd) --->|                   |
 |                 |<--[3] SH, EE, CERT_R, FIN_R ------------|
 |<--[4] SH', EE', CERT'_R, FIN'_R ------|                   |
 |--[5] Finished_I --------------------->|                   |
 |                 |--[6] Finished'_I --->|                  |

This figure summarizes the RN-relayed handshake flights and where forwarding occurs.¶

Legend:¶

[1]

CH1: ClientHello_I, EID_I, Grant¶

[2]

CH1': Forwarded ClientHello_I¶

[3]

SH, EE, CERT_R, FIN_R¶

[4]

SH', EE', CERT'_R, FIN'_R¶

[5]

Finished_I (initiator final confirm towards RN)¶

[6]

Finished'_I (forwarded initiator confirm towards responder)¶

6.1. AEAD Tag Length

The AEAD tag length is algorithm-dependent but subject to the following constraints:¶

• Implementations MUST use a tag length of at least 96 bits for all UZP application data records.¶

• When an AEAD algorithm allows variable tag lengths, endpoints SHOULD use the algorithm's full tag length (typically 128 bits for AES-GCM) and MUST NOT negotiate a tag length below 96 bits.¶

• The tag length used for a session is fixed for the lifetime of that session and is implied by the negotiated cipher suite.¶

This requirement follows common practice in modern protocols, which treat 96 bits as a practical lower bound on AEAD authentication tags for wide-area deployments, while allowing future AEADs with different native tag lengths.¶

11.1. RN Set Discovery and Eligibility

UZP endpoints that require resilient rendezvous SHOULD maintain one or more currently valid RN Set Statements, or an equivalent accepted RN set carried by bootstrap or recovery artefacts, as defined by UZPIF ([UZPIF]). RN referral by a currently attached RN MAY be used as a hint, but it is not sufficient by itself to make an alternate RN eligible for authorisation-relevant use.¶

At baseline, before first use or failover use, the endpoint MUST validate the RN Set Statement's signature set, scope, validity interval, and epoch or sequence state under the UZPIF common envelope rules and prefer the highest eligible non-conflicting statement for the relevant scope. Where policy permits, endpoints SHOULD keep multiple eligible alternate RNs rather than a single spare path.¶

An endpoint MAY attempt failover only to an alternate RN that is currently policy-eligible for the relevant transport role, trust-domain scope, and session class. Eligibility MUST be derived from externally verifiable artefacts rather than from one RN's private control view.¶

A previously successful RN does not remain eligible merely because it stitched earlier traffic. The endpoint MUST re-evaluate alternate-RN eligibility at failover time against current RN Set Statements, current policy scope, and current distrust or revocation state.¶

11.2. RN Failover Triggers

Endpoints SHOULD treat at least the following conditions as baseline failover triggers:¶

• loss of RN reachability, handshake timeout, or repeated Join failure;¶

• authenticated or otherwise policy-accepted overload, maintenance, or capacity-exhaustion signalling;¶

• signed or otherwise locally accepted evidence of RN misbehaviour;¶

• detected inconsistency between the RN's control claims and the endpoint's currently accepted RN Set Statement, Grant state, or transparency evidence; and¶

• suspected RN partition or divergence that prevents safe continuation of authorisation-relevant operation.¶

Triggering failover changes path selection and rendezvous handling; it does not, by itself, revoke identity, Grants, or other externally verifiable authority. RN loss is an availability event, not an authorisation event.¶

11.3. Endpoint Failover Procedure

When a baseline failover trigger occurs, the endpoint MUST at least:¶

1. transition the association into "failover / rebind" or "closed" and stop treating RN-local control state as authorisation truth;¶

2. freeze new authorisation-expanding actions until required revalidation succeeds;¶

3. retain only the portable state allowed by Section 11.5;¶

4. select an alternate RN only from a currently accepted RN Set Statement or equally trusted bootstrap or recovery artefact;¶

5. establish a new RN attachment and perform a new Join evaluation at the alternate RN;¶

6. present current authorisation artefacts by default, or bounded continuity state only when non-expanding continuity is permitted by policy; and¶

7. return to "stitched" only after alternate-RN eligibility and required revalidation checks succeed; otherwise remain unavailable or terminate cleanly.¶

If no eligible alternate RN can be validated, the association remains unavailable. That is an availability outcome, not an implicit revocation of externally verifiable authority.¶

11.4. Re-Stitching and Continuity State

Re-stitching at an alternate RN requires a new RN attachment and Join evaluation. Fresh presentation of current authorisation artefacts is the default baseline. An alternate RN MAY accept bounded continuity state instead of a fully fresh authorisation presentation only for non-expanding continuity when local policy permits it.¶

Bounded continuity state in UZP MUST be endpoint-presented and cryptographically bound to the authenticated peer identities, the still-valid Grant object identifiers or digests, the accepted RN set, the relevant session or resumption context, and a short expiry. It MUST NOT be an opaque RN-issued assertion that another RN is required to trust blindly.¶

An alternate RN MAY reuse bounded continuity state only when the resulting session scope is unchanged or narrower, the referenced Grant and revocation state remain valid, freshness and replay checks succeed, and no unresolved RN disagreement would make the continuity claim ambiguous. Otherwise the endpoint MUST perform a fresh authorised re-stitch.¶

Before moving from "failover / rebind" back to "stitched", the endpoint and alternate RN MUST revalidate at least the alternate RN's eligibility for the requested role and scope, the currently accepted RN Set Statement or equally trusted bootstrap or recovery artefact, peer identity binding and current Grant or equivalent authorisation state, current revocation or transparency state relevant to the requested action, and the binding, freshness, replay constraints, and expiry of any continuity state presented.¶

11.5. Portable Versus RN-Local State

The baseline portability rule for UZP failover is:¶

• resumable or re-usable state MAY include peer identity bindings, current Grant references, accepted RN Set Statement identifiers, validated revocation or transparency checkpoints, and bounded continuity state accepted under policy;¶

• endpoint-local continuity markers MAY include application mapping state or block-delivery checkpoints only when they remain bound to the same peer identities, Grant scope, and continuity window; and¶

• RN-local state such as stitch handles, relay queue placement, pacing and congestion state, per-RN replay allocations, path observations, and unverified relay buffers MUST be treated as non-portable and MUST be renegotiated or conservatively rebuilt.¶

Session continuity therefore does not imply trust continuity. A resumed or re-stitched transport path MUST still revalidate the authorisation artefacts relevant to the new RN attachment.¶

The fact that some state is portable does not remove the need to revalidate it. Portable state MAY be resumed only after its bindings, scope, freshness, and policy eligibility are rechecked for the new RN attachment.¶

11.6. RN Disagreement and Partition Behaviour

If a currently attached RN and an alternate RN present conflicting control views for the same session, scope, or Grant state, endpoints MUST treat the conflict as an availability or continuity issue rather than as proof that either RN is the mandatory truth source.¶

Under RN disagreement or suspected partition, endpoints MUST suspend new authorisation-expanding actions such as new peer scopes, broader Grants, QoS expansion, or 0-RTT resumption that depends on disputed state until externally verifiable artefacts are revalidated. Endpoints MAY continue narrowly scoped, already-established non-expanding traffic only within an explicit continuity window allowed by local policy and MUST cease or cleanly terminate once that window expires or required revalidation fails.¶

When disagreement cannot be resolved safely, implementations SHOULD prefer clean session termination or fresh re-stitching over silent failover that preserves apparent continuity without revalidation.¶

If only one RN remains reachable during disagreement or partition, endpoints MUST still treat that RN as a relay path rather than as a truth anchor. They MUST ignore RN-local claims that would expand authority unless those claims are independently supported by externally verifiable artefacts.¶

12.1. PoR Object Fields

When a PoR challenge, response, or retained liveness artefact is represented as an object, it MUST use the common signed artefact envelope defined by UZPIF ([UZPIF]) with "object_type" set to "por-evidence". In addition to the common envelope, a minimal PoR object MUST carry:¶

• the challenger identity, typically mapped to "audience_id" or an equivalent field;¶

• the responder identity, typically mapped to "subject_id" or an equivalent field;¶

• the RN identifier;¶

• session context sufficient to prevent replay across unrelated sessions, tunnels, or transport bindings;¶

• the PoR nonce;¶

• an issuance time and an expiry time;¶

• a proof-profile identifier indicating which authenticated responder construction was used;¶

• the responder proof value;¶

• a responder key identifier or exporter-label reference when needed for verification; and¶

• optional grant, transport-binding, or transparency references when the deployment needs them for audit or replay tracking.¶

These fields populate the PoR-specific body only. UZP inherits the UZPIF common envelope unchanged, including canonical serialisation, exact signature coverage, object identifiers, unknown extension handling, signature ordering, algorithm identifier matching, epoch-versus-sequence precedence, and the rule that detached signatures are not part of baseline interoperability.¶

When a PoR artefact is retained as a common signed object, the envelope signature set authenticates the retained artefact representation for exchange or audit. It does not replace the responder proof value as the liveness proof itself. Current reachability still depends on validating the responder proof against the profile-defined authenticated responder for the challenged context.¶

The responder proof value MUST authenticate the exact PoR input used by the selected proof profile. At a minimum, that authenticated input MUST cover the responder identity, the challenger identity or equivalent audience restriction, the RN identifier, the session context, the PoR nonce, the issuance and expiry values, the proof-profile identifier, and any grant, transport-binding, or transcript-binding values that the verifier is expected to enforce. If a profile authenticates a derived challenge representation rather than the retained PoR object verbatim, the verifier MUST still be able to determine exactly which PoR fields were authenticated.¶

12.2. PoR Exchange

A PoR exchange is defined as follows:¶

1. The client generates a fresh nonce for a specific PoR transaction. The nonce MUST be unique within the verifier's active replay window for the relevant responder, RN context, and session class.¶

2. The PoR challenge MUST bind: the peer identity being tested, a fresh nonce, an RN identifier, an explicit expiry window, and session context sufficient to prevent replay across unrelated sessions or tunnels.¶

3. The RN relays the nonce to the target peer without modification.¶

4. The peer produces proof material using the profile-defined authenticated responder for the current session, covering the bound challenge fields and the authenticated session or transport context required by that profile.¶

5. The RN returns the responder proof to the client.¶

6. The client validates the returned proof against the exact challenged context, including nonce freshness, expiry, session-context binding, proof-profile identifier, and peer identity match, before accepting liveness.¶

Freshness evaluation MUST reject a PoR response if the nonce was not generated for the claimed transaction, if that nonce has already been accepted for the same responder or context, if the issuance or expiry values fall outside the verifier's acceptance window, or if the authenticated session, resumption, or transport context is no longer current.¶

A verifier MUST also reject a response if the challenge expiry has elapsed before proof validation completes, if the authenticated RN identifier does not match the RN attachment under evaluation, or if the proof binds to an older session, resumption context, or continuity window than the one for which present reachability is being claimed.¶

12.3. PoR Across Re-Stitch and RN Failover

PoR evidence is path- and context-bound. A PoR response accepted under one RN attachment, session context, or continuity window MUST NOT by itself be treated as fresh liveness proof for a different RN attachment or re-stitched transport path.¶

After re-stitch or RN failover, endpoints MUST obtain a new PoR response bound to the new RN identifier and the currently authenticated session or continuity context before relying on PoR for current reachability on that path. Earlier PoR artefacts MAY be retained for audit, replay tracking, or continuity diagnostics, but they do not satisfy current liveness verification for the new attachment.¶

A previous PoR response MUST NOT be reinterpreted as current liveness merely because the same peer identities, Grant references, or application flow continue across failover. The verifier MUST obtain a fresh proof bound to the new RN attachment and current session or continuity context before treating the peer as presently reachable on that path.¶

A bounded continuity decision under Section 11.4 MAY allow traffic to continue briefly while revalidation proceeds, but it does not convert an older PoR bound to a previous RN or session into proof of present reachability.¶

12.4. TLS-DPA PoR Profile

The TLS-DPA profile instantiates the authenticated responder using TLS-DPA-authenticated identity material [TLS-DPA]. A deployment MAY use either:¶

• a dedicated PoR responder key derived from exporter material bound to the authenticated TLS-DPA or UZP session; or¶

• a proof directly generated with TLS-DPA-authenticated identity key material.¶

The TLS-DPA profile SHOULD prefer an exporter-derived PoR responder key for steady-state or frequent liveness checks because it reduces operational dependence on repeated use of long-term identity keys while preserving RN non-forgeability. Direct long-term identity-key signing MAY be used where policy explicitly requires identity-key participation or where exporter-derived responder material is unavailable.¶

In the TLS-DPA profile, exporter-derived responder material is the preferred baseline for ordinary PoR use. Long-term identity-key signatures are an exception path for deployments that explicitly require them, for recovery of exporter state, or for other policy-defined cases where exporter-derived proof material cannot be used.¶

Regardless of which method is used, the client MUST validate that the responder proof is cryptographically bound to a TLS-DPA-authenticated peer identity and to the relevant session context. The authenticated input MUST cover the PoR nonce, the asserted identities, the RN identifier, validity bounds, and the session or exporter binding required by the selected mode.¶

This draft intentionally does not define a byte-level PoR wire encoding for the TLS-DPA profile. Profile documents or future revisions may define concrete serialisations for PoR challenges, PoR responses, and retained PoR artefacts while preserving the object fields and validation rules specified here.¶

12.5. Replay Prevention

Replay prevention requirements for PoR are:¶

• Peers and verifiers MUST reject expired nonce values or challenges whose validity window has elapsed.¶

• Verifiers MUST accept a PoR response at most once for a given responder identity, RN identifier, nonce, and session-context tuple.¶

• RNs MUST NOT treat replayed forwarding, repeated observation, or cached PoR responses as fresh liveness, and MUST NOT cache PoR responses beyond their expiry window.¶

Replay prevention for PoR is therefore based on nonce uniqueness, bounded validity, exact context binding, and verifier-side single-acceptance tracking rather than on RN observation of traffic.¶

12.6. RN Non-Forgeability Requirement

The transport liveness model MUST ensure an RN cannot fabricate peer reachability.¶

• The peer PoR proof MUST cover the original nonce, peer identity, RN identifier, expiry condition, and session context.¶

• The client MUST validate the proof against the profile-defined authenticated responder associated with the peer identity, and MUST NOT rely on RN assertions alone for liveness.¶

• RNs MUST NOT generate synthetic PoR acknowledgements that are not produced by the authenticated responder bound to the peer identity and session context.¶

• RN-local evidence such as successful forwarding, packet observation, queue drain, or timing correlation MUST NOT be substituted for endpoint-generated PoR proof.¶

12.7. Liveness Proof Logging

RNs MAY publish aggregated PoR statistics in transparency logs. Publication is OPTIONAL but RECOMMENDED for deployments that use merit-based scoring or external audit signals.¶

Where PoR-related transparency artefacts are published for interoperable audit, they MUST use the common signed artefact envelope defined by UZPIF ([UZPIF]), with sequence or log linkage sufficient for independent audit.¶