Use Cases and Requirements for Network Admission of AI Agent Instances
draft-shang-agent-network-admission-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) | |
|---|---|---|---|
| Authors | Chao Shang , weiyu Jiang , Liang Xia , Bizhu Wang , Mengying Sun | ||
| Last updated | 2026-07-06 | ||
| 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-shang-agent-network-admission-01
Individual Submission C. Shang
Internet-Draft W. Jiang
Intended status: Informational X. Liang
Expires: 7 January 2027 Huawei
B. Wang
M. Sun
Beijing University of Posts and Telecommunications
6 July 2026
Use Cases and Requirements for Network Admission of AI Agent Instances
draft-shang-agent-network-admission-01
Abstract
Artificial intelligence (AI) agents increasingly access enterprise
resources, external models, tools, and other agents through managed
networks. Application-layer authentication can authenticate an agent
to a cooperating service, but it cannot by itself provide complete
network admission control. In particular, application proofs are
normally verified only after network reachability exists, cannot be
consumed consistently by heterogeneous or legacy services, and do not
reliably identify which Agent Instance originated traffic when
multiple Agents share one host, IP address, or egress gateway.
This document describes operational use cases, the resulting problem
statement, and requirements for network admission of AI Agent
Instances. It focuses on establishing a verifiable and time-bounded
binding among an Agent Instance, its credential key, optional runtime
evidence, and a Network Context on which the network can enforce
reachability policy. This document does not define a new Agent-ID
format, authentication protocol, OAuth grant, or routing extension.
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/.
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."
Shang, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Agent Network Admission July 2026
This Internet-Draft will expire on 7 January 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Enterprise Employee Device with Multiple Agents . . . . . 5
3.2. Enterprise Agent Accessing Internal and External
Services . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Multiple Agents behind a Shared Egress Gateway . . . . . 6
3.4. Dynamically Created and Short-Lived Agents . . . . . . . 7
3.5. Agent-to-Agent Collaboration in a Managed Network . . . . 7
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Network Enforcement Is Required but Lacks Agent
Granularity . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. One IP Address Can Represent Multiple Security
Subjects . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Agent Identity Does Not Automatically Provide Traffic
Attribution . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Admission Must Precede General Reachability . . . . . . . 10
4.5. Agent Lifecycle and Network Lifecycle Are Different . . . 10
5. Requirement Summary . . . . . . . . . . . . . . . . . . . . . 10
5.1. Agent Instance Authentication . . . . . . . . . . . . . . 10
5.2. Binding Identity to Enforceable Traffic . . . . . . . . . 10
5.3. Shared-Gateway Attribution . . . . . . . . . . . . . . . 11
5.4. Admission, Lifetime, and Revocation . . . . . . . . . . . 11
5.5. Non-Bypassability and Layered Authorization . . . . . . . 11
5.6. Evidence, Audit, and Privacy . . . . . . . . . . . . . . 12
6. Functional Model . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
Shang, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Agent Network Admission July 2026
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
AI agents increasingly perform enterprise tasks without continuous
human supervision. They retrieve internal documents, query
databases, invoke Model Context Protocol (MCP) servers and Web APIs,
call external models, communicate with other Agents, and initiate
long or multi-step workflows. These activities ultimately produce
network connections that cross access networks, campus fabrics, cloud
virtual networks, security gateways, and Internet egress points.
Application-layer mechanisms are necessary but are not sufficient for
complete Agent admission control. Workload identity, mutual TLS,
signed HTTP messages, OAuth tokens, and proof-of-possession
mechanisms can allow a cooperating application peer to authenticate
or authorize an Agent. However, these mechanisms normally operate
only after the Agent already has a path to the peer. They also
require the peer to understand and enforce the Agent identity. This
assumption is difficult to satisfy across heterogeneous, legacy,
third-party, and non-HTTP services.
For these reasons, part of the control needs to be performed at the
network admission layer. The network is the common enforcement point
traversed by Agent traffic and can restrict reachability before a
specific application accepts a request. Network enforcement does not
replace application-layer authorization; it provides an earlier and
broader control boundary.
Existing network admission mechanisms, including EAP [RFC3748] and
EAP-TLS [RFC5216] [RFC9190], commonly authenticate a device, host,
user, or supplicant. The resulting authorization is typically
associated with a physical port, wireless association, virtual
interface, tunnel, or source address. This granularity is
insufficient when several Agent Instances and ordinary applications
share the same host and IP address.
The key new problem is therefore not merely how to assign an Agent-
ID, but how to authenticate a specific running Agent Instance and
bind that result to a Network Context that cannot be reused by
another local process. The following use cases illustrate this
problem.
Shang, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Agent Network Admission July 2026
Existing mechanisms for workload identity, Agent authentication,
application authorization, runtime attestation, and Agent-aware
networking may provide credentials, authorization decisions, runtime
evidence, or Agent-related context. This document does not replace
those mechanisms. It focuses on the distinct deployment question of
how an authenticated Agent Instance and its relevant security
attributes are bound to a Network Context on which network
reachability policy can be enforced, particularly when multiple Agent
Instances share a host, source address, or egress gateway.
2. 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.
Agent: Software that performs tasks on behalf of a Principal and may
autonomously invoke services, tools, or other agents.
Agent Instance: A particular running instantiation of Agent
software. Two executions of the same image or package are
distinct Agent Instances unless continuity is explicitly and
securely preserved.
Agent Identifier (Agent-ID): An identifier for an Agent Instance.
An Agent-ID is an assertion, not proof, unless it is
cryptographically bound to an authenticated key or credential.
Agent Credential: A certificate, signed token, workload credential,
proof-of-possession credential, or other verifiable object used to
authenticate an Agent Instance.
Agent Runtime: The process, container, virtual machine, trusted
execution environment, or other execution context in which an
Agent Instance runs.
Network Admission Function (NAF): The function that verifies Agent
admission evidence and decides whether an Agent Binding may be
installed.
Enforcement Point (EP): A network entity that applies reachability
or traffic policy based on an Agent Binding.
Agent Binding: A time-bounded association among an authenticated
Agent Instance, the key proved during admission, relevant security
attributes, and an enforceable Network Context.
Shang, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Agent Network Admission July 2026
Network Context: Network-visible or network-controlled state that
associates traffic with an Agent Instance, such as a logical
interface, virtual port, a trusted namespace-associated interface,
overlay identity, anti-spoofed source address, security
association, tunnel, connection, or trusted per-Agent gateway
context.
Principal: The user, organization, service, or other entity on whose
behalf an Agent acts.
3. Use Cases
3.1. Enterprise Employee Device with Multiple Agents
An employee device may simultaneously run a personal assistant, a
coding Agent, an enterprise knowledge Agent, browser automation, and
ordinary user applications. Some Agents may be approved by the
enterprise, while others may be downloaded by the user or created
dynamically by an orchestration framework.
Enterprise Network
|
+------+------+
| Access Edge |
+------+------+
|
one device / one IP
|
+----------------+----------------+
| |
+------+-------+ +------+-------+
| Approved | | Other Local |
| Agent A | | Processes |
+--------------+ +--------------+
+--------------+ +--------------+
| Approved | | Unapproved |
| Agent B | | Agent C |
+--------------+ +--------------+
Figure 1: Multiple Agents sharing one admitted host
Traditional device admission authenticates the device or user and
then associates policy with the shared attachment or source IP
address. It cannot determine whether a subsequent connection was
created by Agent A, Agent B, Agent C, or an ordinary process. Source
ports, process names, and self-asserted headers are controlled by the
host and can be copied or reused.
Shang, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Agent Network Admission July 2026
The enterprise needs to grant different reachability to each approved
Agent Instance while preventing the unapproved Agent from inheriting
the device's network permissions.
3.2. Enterprise Agent Accessing Internal and External Services
An enterprise Agent may retrieve data from an internal knowledge
base, call an external large-model service, and invoke a Software as
a Service (SaaS) API as part of one task. The internal services may
use different authentication technologies, and some legacy services
may not understand Agent identities at all.
+-----------+ +----------------+ +------------------+
| Agent |------>| Campus / Cloud |------>| Internal Service |
| Instance | | Network | +------------------+
| | | Enforcement |------>| External Model |
+-----------+ +----------------+ +------------------+
->| SaaS / Web API |
+------------------+
Figure 2: Agent access across heterogeneous services
Relying only on application-layer authentication requires every
destination to understand the Agent credential and to apply
consistent policy. This is not realistic for heterogeneous and
legacy services. Moreover, the Agent must already have network
reachability before the remote service can reject it.
The network therefore needs to restrict which destinations the Agent
can reach based on an authenticated Agent Instance, while
application-layer authorization continues to restrict operations at
cooperating services.
3.3. Multiple Agents behind a Shared Egress Gateway
Enterprises commonly require Agents to access external services
through a security gateway, service mesh proxy, or controlled egress
gateway. Several Agents may share one public IP address, a gateway
connection pool, or even a single multiplexed HTTP/2 or HTTP/3
connection toward the same external service.
Agent A ----+
Agent B ----+--> Shared Egress Gateway --> External Service
Agent C ----+
Figure 3: Multiple Agents behind one egress gateway
Shang, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Agent Network Admission July 2026
The external service may distinguish gateway-originated transport
connections, HTTP requests, or multiplexed streams. However, a
source port, connection, request, or stream identifies only gateway-
maintained forwarding state and does not by itself provide
authenticated identity of the originating Agent Instance.
The external service can authenticate the gateway, but gateway
authentication alone does not prove which Agent Instance caused a
particular request. Reliable attribution requires the gateway to
receive or establish trustworthy per-Agent context and to propagate
that context using a protected mechanism, such as an Agent-specific
credential, token, or signed assertion. If the gateway receives only
an unprotected Agent-ID header, one Agent may select another Agent's
identity or policy context.
The gateway therefore needs trustworthy per-Agent admission state and
isolation among Agent credentials, requests, connections, and policy
contexts. When connections are pooled or multiplexed, the gateway
must preserve the binding between each request and the originating
Agent Instance. The local network also needs to prevent an Agent
from bypassing the gateway through another path.
3.4. Dynamically Created and Short-Lived Agents
An orchestration platform may create an Agent for a single task,
create sub-Agents, restart an Agent after failure, migrate it to
another runtime, or terminate it within minutes. The host and its
device-level admission session may remain active for days.
A device-level network session therefore outlives many Agent
Instances. A new Agent execution must not automatically inherit the
admission state of a previous execution merely because it uses the
same image, host, or IP address. Admission state needs an Agent-
specific lifetime and must be removed when the Agent terminates,
migrates, or becomes non-compliant.
3.5. Agent-to-Agent Collaboration in a Managed Network
A group of Agents may collaborate on one enterprise task. For
example, a planning Agent invokes a retrieval Agent, which then
invokes a data-analysis Agent. The Agents may run on the same host,
on different enterprise hosts, or across branch and cloud networks.
Shang, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Agent Network Admission July 2026
The network may need to permit only an approved collaboration graph
and deny unrelated Agent-to-Agent reachability. Device identity is
too coarse when multiple Agents share an endpoint, and application
authentication alone does not stop unauthorized network scanning,
connection attempts, or bypass paths before the application protocol
is reached.
4. Problem Statement
4.1. Network Enforcement Is Required but Lacks Agent Granularity
Application-layer authentication answers whether a cooperating
service accepts an Agent credential. Network admission answers
whether an Agent Instance should receive reachability to a
destination or network segment. These are complementary controls.
Application-layer mechanisms cannot fully provide network admission
because:
* they are usually evaluated only after a network path is available;
* they require every destination to understand the Agent identity;
* they cannot consistently cover legacy, third-party, and non-HTTP
services;
* they do not prevent connection attempts, scanning, or bypass
paths; and
* their result is not automatically available to switches, virtual
switches, routers, or security gateways that enforce reachability.
Network-layer enforcement is therefore needed as a common pre-service
control point. However, existing network admission commonly
associates identity with a device, user, interface, tunnel, or IP
address rather than a specific Agent Instance.
4.2. One IP Address Can Represent Multiple Security Subjects
A single IP address may simultaneously carry traffic from multiple
approved Agents, unapproved Agents, ordinary applications, and the
user. Therefore:
one source IP address
|
+-------+-------+-------+
| | |
Agent A Agent B Other Process
Shang, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Agent Network Admission July 2026
The following implications hold:
* successful device authentication does not authenticate every
Agent;
* a source IP address is not an Agent identity;
* a transport source port is not a stable or trustworthy Agent
identity;
* an Agent-ID in a host-controlled header is not sufficient proof;
and
* application credentials do not by themselves bind all surrounding
traffic to the process that owns the credential.
Different admission policies for multiple Agents sharing one IP
address therefore require an additional trusted per-Agent Network
Context.
4.3. Agent Identity Does Not Automatically Provide Traffic Attribution
Existing Agent identity and workload identity work can define who the
Agent is and how it proves possession of a credential key. Existing
OAuth work can define what the Agent is authorized to do at a
Resource Server. Existing attestation work can provide evidence
about the runtime.
None of these functions alone establishes which packets, connections,
or flows at a local network EP belong to the authenticated Agent
Instance. The missing function is a verifiable binding:
Authenticated Agent Instance
+
Credential-Key Possession
+
Optional Runtime Evidence
+
Enforceable Network Context
=
Agent Binding
The Network Context must be controlled or protected such that another
local process cannot simply reuse it. Examples may include a per-
Agent namespace, virtual port, tunnel, security association, anti-
spoofed address, or trusted gateway context.
Shang, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Agent Network Admission July 2026
4.4. Admission Must Precede General Reachability
An Agent requires limited connectivity to identity, credential,
attestation, and remediation services in order to complete admission.
It should not receive unrestricted enterprise or Internet
reachability before that process finishes.
A deployment therefore needs a constrained pre-admission state and a
controlled transition to Agent-specific reachability after the Agent
Binding is installed.
4.5. Agent Lifecycle and Network Lifecycle Are Different
Agent Instances may be created, restarted, cloned, suspended,
migrated, or terminated independently of the host network session. A
static device or IP binding can therefore become stale and may
unintentionally authorize a new Agent execution.
Agent admission state must have an independent lifetime and explicit
renewal, revocation, migration, and termination behavior.
5. Requirement Summary
Based on the preceding use cases and problem statement, an Agent
network admission architecture has the following core requirements.
5.1. Agent Instance Authentication
The architecture MUST authenticate a particular Agent Instance, or an
explicitly defined instance-continuity domain, using a credential
bound to a cryptographic key or equivalent proof mechanism. The
Agent Instance MUST prove possession of that key with freshness
protection.
Authentication of only a user, device, host, image, Agent software
class, or orchestration platform MUST NOT be treated as
authentication of every Agent Instance running there. Self-asserted
identifiers, process names, source ports, or unprotected application
headers MUST NOT be sufficient for admission.
5.2. Binding Identity to Enforceable Traffic
A successful authentication result MUST be bound to a Network Context
on which an EP can enforce policy. The binding MUST identify which
traffic is covered and MUST be protected against reuse by another
local process.
Shang, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Agent Network Admission July 2026
When multiple Agents share a host, interface, source address, or
gateway, the deployment MUST provide a trusted means to distinguish
their traffic. A source address MAY be used only when address
ownership and anti-spoofing are enforced at the relevant attachment.
5.3. Shared-Gateway Attribution
A gateway serving multiple Agents MUST authenticate, or receive
authenticated context for, each originating Agent Instance. It MUST
isolate per-Agent credentials and policy state and prevent one Agent
from selecting or reusing another Agent's context.
When connections are pooled or multiplexed, the gateway MUST preserve
the binding between each request and the originating Agent Instance.
Gateway authentication alone MUST NOT be represented as proof of the
originating Agent unless that binding is securely preserved and
conveyed to the remote peer through a protected mechanism.
5.4. Admission, Lifetime, and Revocation
Before admission completes, an Agent Instance SHOULD have only the
minimum connectivity required for identity, credential, attestation,
remediation, and admission services. General reachability SHOULD be
denied until an Agent Binding is installed.
Every Agent Binding MUST have a finite lifetime. A restart, clone,
or migration MUST NOT automatically inherit an old binding unless
continuity is explicitly proven. The deployment MUST support renewal
and prompt removal of the binding when the Agent terminates, its
credential is revoked, its runtime becomes non-compliant, its
attachment changes, or policy requires withdrawal.
5.5. Non-Bypassability and Layered Authorization
The topology and enforcement configuration MUST prevent Agent traffic
from bypassing the EP through alternate interfaces, direct underlay
access, unprotected gateways, or other paths.
Successful network admission establishes authenticated and
constrained reachability; it MUST NOT imply unrestricted application
authority. The Principal identity and Agent-ID MUST remain
distinguishable, and an Agent MUST NOT automatically inherit all
reachability or authority of its Principal.
Shang, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Agent Network Admission July 2026
5.6. Evidence, Audit, and Privacy
When runtime or platform evidence is used, it MUST be bound to the
same Agent Instance key and admission context. The NAF and EP SHOULD
record the Agent Instance, verified credential, installed Network
Context, and binding lifecycle events.
Deployments SHOULD minimize disclosure and retention of Principal
identity, Agent identifiers, and runtime measurements, and SHOULD use
short-lived or locally scoped identifiers where appropriate.
6. Functional Model
+--------------------+ +-------------------------+
| Agent Instance | | Identity / Attestation |
| | | Services |
| instance key | +------------+------------+
+---------+----------+ |
| admission proof | validation data
v v
+---------+-------------------------------------------+
| Network Admission Function |
| verifies credential, possession, freshness, |
| optional runtime evidence, and policy |
+--------------------------+--------------------------+
| install Agent Binding
v
+--------------------------+--------------------------+
| Network Enforcement Point |
| Agent-ID / key / attributes -> Network Context |
+--------------------------+--------------------------+
|
admitted traffic
v
Network Resources
Figure 4: Agent Instance network-admission model
A deployment MAY distribute these functions across an endpoint
component, network device, controller, and gateway. The security
property depends on the integrity of the complete path from the
authenticated Agent key to the Network Context, not on the physical
location of one component.
Shang, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Agent Network Admission July 2026
7. Security Considerations
The primary security failure is a false association between an
authenticated Agent-ID and traffic generated by another entity.
Implementations need to protect both the cryptographic proof and the
local mechanism that creates and uses the Agent Binding.
Bearer credentials are insufficient when they can be copied to
another process or host. Proof-of-possession credentials reduce this
risk only when the private key is protected and the proof is bound to
the admission session and Network Context.
Runtime attestation does not replace Agent Instance authentication.
Agent Instance authentication does not by itself prove that the
runtime is trustworthy. Deployments requiring both properties need
an explicit binding among the runtime evidence, Agent Instance key,
and Network Context.
A trusted gateway can preserve Agent attribution across a second
connection, but it becomes a high-value security boundary. It needs
per-Agent isolation, protected binding state, anti-replay protection,
and clear behavior when either side of the communication is re-
established. Connection pooling and HTTP/2 or HTTP/3 multiplexing
must not cause requests from different Agent Instances to inherit or
reuse the wrong Agent context.
8. Privacy Considerations
Agent admission can expose relationships among a Principal, an Agent
Instance, a device, a runtime, and its destinations. Stable Agent-
IDs may permit tracking across tasks or administrative domains.
Deployments should minimize identifier scope and retention, disclose
only attributes required by policy, and avoid unnecessary export of
runtime evidence.
9. IANA Considerations
This document makes no requests of IANA.
10. Acknowledgements
The authors thank participants in the IETF Agent identity, WIMSE,
RATS, OAuth, and Agent-aware networking discussions whose work helped
clarify the boundary between application authentication and network
admission.
11. References
Shang, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Agent Network Admission July 2026
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.
Authors' Addresses
Chao Shang
Huawei
Email: chao.shang@huawei.com
Weiyu Jiang
Huawei
Email: jiangweiyu1@huawei.com
Liang Xia
Huawei
Email: frank.xialiang@huawei.com
Bizhu Wang
Beijing University of Posts and Telecommunications
Email: wangbizhu_7@bupt.edu.cn
Shang, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Agent Network Admission July 2026
Mengying Sun
Beijing University of Posts and Telecommunications
Email: smy_bupt@bupt.edu.cn
Shang, et al. Expires 7 January 2027 [Page 15]