Zero trust standards in IETF: use cases and problem statement

Introduction Traditional network security was built on the assumption of that every entity inside the perimeter were trusted by default. This approach is increasingly ineffective in face of new use cases and sophisticateed attackers. Zero Trust (ZT) offers a fundamentally different approach. As d efined in [NIST-SP-800-207], Zero Trust assumes no implicit trust is granted to assets or user accounts based solely on their physical or network location. Instead, authentication and authorization are discrete, dynamic functions that must be performed before a session is established to an enterprise resource. This is a "never trust, always verify" model. While this conceptual framework is powerful, its practical implementation is hampered by a lack of open standards. Today's ZT solutions are largely proprietary, single-vendor ecosystems. An organization cannot easily use a Policy Enforcement Point (PEP) from one vendor with a Policy Decision Point (PDP) from another. This document provides a gap analysis for zero trust standardization, as well as several typical use cases. In additon, it also discusses the scope of standardization of zero trust in the IETF.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology This document adopts the core terminology defined in .

Subject:: An entity (e.g., user, device, service, application, AI agent) that requests access to a resource.
Resource:: A data source, service, device, or network component that a subject wishes to access.
Policy Engine (PE):: The component responsible for the ultimate decision to grant or deny access to a resource for a given subject.
Policy Administrator (PA):: The component responsible for establishing and/or shutting down the communication path between a subject and a resource.
Policy Enforcement Point (PEP):: A system responsible for enabling, monitoring, and terminating connections between a subject and a resource. The PEP communicates with the PA to forward requests and/or receive policy updates.
Control Plane:: The logical network of communication that is used to manage the ZTA. This includes communication between the PE, PA, and PEPs, as well as the collection of context and signals.
Data Plane:: The logical network where subjects and resources communicate after access has been granted.

Use cases In this section we consider several emerging use cases where standardized ZT protocols would provide significant value.

Use Case 1: Secure Remote Access for Enterprise Resources A remote employee needs to access an internal application hosted in a private data center of an organization.

Subject: The employee's user identity and the device identity.
Resource: The internal application.

Use case 2: secure service-to-service communication A front-end web service running in a Kubernetes cluster in Cloud A needs to query a database service running in a VM in Cloud B.

Subject: The front-end web service, identified by a workload identity.
Resource: The database service.

Use Case 3: Granular Access to Third-Party SaaS Applications An organization wants to enforce device posture checks before allowing employees to access a third-party SaaS application .

Subject: The employee and their device.
Resource: The SaaS CRM application.

Use Case 4: Secure Access for Autonomous AI Agents An autonomous AI agent, acting on behalf of a user or system, needs to access a set of APIs to complete a task (e.g., booking travel).

Subject: The AI agent, possessing a cryptographically verifiable workload identity.
Resource: A set of airline, hotel, and payment gateway APIs.

Problem statement The implementation of zero trust is hindered by several key problems that may be addressed by standardization.

Lack of interoperability The core components of ZTA, PE, PA and PEP currently communicate with each other using proprietary protocols. Different components from different vendors can barely communicate and interoperate with each other. This makes an organization wishing to implenment ZTA system probably forced to source all components from one single vendor. This creates silos where the ZT system for employee access is completely separate from the ZT system for cloud service-to-service communication, even though the underlying principles are the same. A unified approach requires common standards.

Market Confusion Without clear, protocol-level definitions and specifications, the term "zero trust" is often used as marketing buzzword rather than technology or product langauge. Products with different capabilities and features can be all labeled as "zero trust enabled". Standardization can enhance clarity by clearly document the requirements for components to participate in ZTA system from the protocol and funtionality level.

Gap Analysis While the IETF and other SDOs have produced fundamental building blocks, there still lacks a complete, interoperable ZT standard framework. A significant gap exists between the available components and a functioning ZTA control plane. Specifically, the main gaps can be concluded as follows.

A Standardized Control Plane Protocol: This is the central gap. There is no standard protocol for a PEP to request an access decision from a PE, nor for the PE/PA to return a dynamic policy decision. Today, this critical interaction is implemented with proprietary REST APIs with vendor-specific data models.
A Standardized Signal Exchange Protocol: A PE's decisions rely on continuous streams of context (signals). While RATS defines attestation formats, there is no standard protocol for how diverse sources (EDR systems, threat feeds, IdPs) publish these signals and how a PE consumes them. This prevents the creation of a multi- vendor "nervous system" for the ZTA.
A Model for Dynamic, Fine-Grained Authorization: OAuth scopes are often broad and long-lived. ZT demands just-in-time, least- privilege access. A standard is needed to model a request for, and issuance of, highly specific and ephemeral access rights (e.g., "grant subject X write access to record Y in database Z for the next 30 seconds").
A framework for dynamic and continuous trust evaluation: The core principle of Zero Trust is continuous verification. This implies a mechanism for dynamically evaluating the trustworthiness of a subject over time. While individual signals (like device posture or user location) are important, there is no standardized framework for aggregating these signals into a dynamic trust score or confidence level. Furthermore, there is no standard protocol for how this trust score is updated in near-real-time and communicated to the Policy Engine to influence access decisions. Defining such a framework would enable interoperable trust assessment modules and allow the PE to make more nuanced, risk-based decisions beyond a simple grant/deny.

To be successful, an IETF effort must have a clearly defined scope. We propose focusing on the communication interfaces between ZTA components, directly addressing the gaps identified in .

The highest priority is to define a standard protocol for a PEP to request an access decision from a PE/PA and for the PE/PA to return a decision and policy configuration. This could be a new protocol or a profile of an existing one (e.g., using HTTP APIs with a well-defined JSON data model). It must specify how to represent the subject, resource, and context in a request, and how to represent grant, deny, or step-up authentication decisions in a response.

A ZTA's decisions are only as good as the signals it receives. A standardized protocol is needed for various sensors (e.g., EDR agents, threat intelligence feeds, IdPs) to publish signals to a centralized bus or directly to the PE. This would allow a PE to consume signals from multiple vendors' security tools. This work should align with and leverage concepts from the IETF RATS and SCITT working groups.

While TLS provides a secure channel, ZTA introduces new challenges. Work could be done to standardize how a PA instructs a PEP to establish a session. This might involve profiling the use of existing protocols or defining mechanisms for securely delivering short-lived, session-specific credentials (e.g., tokens or certificates) to the subject and/or PEP as part of an access grant.

IANA Considerations This memo includes no request to IANA.