Protocol Gap Analysis for Zero Trust
Control and Policy Interoperability
Overview for IETF ZTCPP
Why Zero Trust still lacks interoperable connectivity control-plane semantics
POLICY
PLANE
↓
CONTROL
PLANE
↓
SESSION /
FLOW
Identity-agnostic, service-centric interoperability for human and non-human connectivity
IETF ZTCPP Gap Analysis
Philip Griffiths
The structural flaw
Traditional TCP/IP networking establishes reachability before identity and policy are evaluated.
If a service is addressable, it is discoverable and reachable before authorization.
This connect-then-authorize ordering creates systemic exposure that Zero Trust is supposed to reduce.
Connect first, authorize later is the wrong default — across users, workloads, and services.
The paper’s architectural thesis
IETF ZTCPP Gap Analysis
Philip Griffiths
3
What this paper is - and is not
A CSA/NIST-aligned framing for the IETF ZTCPP effort
This paper IS
Connectivity control plane = how policy is expressed, distributed, updated, revoked, and bound to sessions/flows with verifiable enforcement.
This paper is NOT
But posture, attestation, and context signals — and their protocol interactions — are in scope because dynamic trust is central to operational Zero Trust.
IETF ZTCPP Gap Analysis
Philip Griffiths
The three interoperability seams
Three seams define the control-plane problem.
The seams are distinct because they govern different failure modes:
Three distinct interaction surfaces — exposure, control, and runtime enforcement
IETF ZTCPP Gap Analysis
Philip Griffiths
5
What this seam must guarantee
What breaks without it
Seam 4.1: Gateway <-> Resource
Identity-bound�overlay / mediated�connectivity
Authenticated-before-connect (ABC) and resource-hiding at the exposure boundary
Exposure reduction matters - but exposure reduction is not the whole control plane.
IETF ZTCPP Gap Analysis
Philip Griffiths
6
Controller
Gateway
Agent
Router
register • advertise capability • push/update policy • reauth/revoke • report status
4.2 pushes lifecycle decisions from controller to distributed EPs
What this seam must guarantee
What breaks without it
Policy must move, adapt, and revoke consistently.
Seam 4.2: Controller <-> Enforcement Point
Dynamic trust and policy lifecycle between controller and EPs
IETF ZTCPP Gap Analysis
Philip Griffiths
7
Policy
Decision
Bound Service
Session / Flow
Identity
Service
Context
These inputs must survive contact with the data plane
without dilution into coarse address-based controls.
4.3 is where least privilege becomes observable and verifiable based on strong identity.
What this seam must guarantee
What breaks without it
Least privilege must survive contact with the data plane.
Seam 4.3: Policy Plane <-> Data Plane
Runtime binding of policy intent to concrete sessions and flows
IETF ZTCPP Gap Analysis
Philip Griffiths
8
Key protocol gaps identified in the paper
Section 6 organizes standardization opportunities around seven gaps
G1 Controller <-> EP lifecycle
Problem
No widely adopted interoperable protocol for registration, capability advertisement, policy update, revocation, refresh, and stale-state handling.
Why it matters
Multi-vendor environments require proprietary integrations and inconsistent lifecycle behavior.
G2 Dynamic trust inputs
Problem
Limited interoperability for how posture, attestation, and context signals trigger policy updates, reauth, or enforcement changes across EPs.
Why it matters
Dynamic trust decisions are not portable across implementations.
G3 Decision binding
Problem
No common model linking least-privilege service policy decisions to concrete sessions, flows, or channels.
Why it matters
Audit, revocation assurance, and service-level enforcement verification remain weak or inconsistent.
G4 ABC composition
How gateway/resource ABC/hiding composes with dynamic trust control planes
G5 Service portability
Service- and NHI-based policy targets across address- and service-centric models
G6 Identity / key composition
External IdPs, PKI/HSM, credential ecosystems, workload identity
G7 HA / degraded mode
Failover, stale policy, re-sync, fail-open/fail-closed/fail-limited
The draft’s center of gravity shifts from “ABC only” to service-based least privilege, runtime binding, and portable control-plane semantics.
IETF ZTCPP Gap Analysis
Philip Griffiths
9
Implementation classes compared
Informative comparison: which seams each class exercises most strongly
Implementation class
Strongest seam(s)
Where it helps most
Where it tends to be weaker
Gateway-centric ABC / hiding
4.1
Eliminates pre-auth exposure; strong ingress/egress mediation
Policy lifecycle, service-level least privilege, end-to-end binding
In-network enforcement
4.2
Control distribution and coordinated enforcement across existing fabrics
Portable service semantics; mapping policy intent to runtime behavior
Overlay / service-centric
4.1 + 4.2 + 4.3
Identity-first service access, runtime binding, service-granular policy
Still needs interoperable semantics rather than vendor-specific control models
This comparison is illustrative, not prescriptive: the point is to show why seam coverage matters, not to pick winners.
IETF ZTCPP Gap Analysis
Philip Griffiths
Takeaways for discussion
1. Controller↔EP control protocol requirements
2. Controller↔EP interoperability framework
3. Policy↔data binding framework
4. Dynamic trust / context profile
5. ABC composition profile
6. Service target abstraction
The missing interoperability layer is the one that binds policy intent to real connections.
Discussion:
Which seam is most urgent for interoperable standardization?
Zero Trust is not interoperable until policy can be portably bound to real sessions and flows.
Why this paper matters for CSA, IETF, and open implementations
IETF ZTCPP Gap Analysis
Philip Griffiths