802.1X EAP-TLS Authentication Sequence 802.1X EAP-TLS 认证时序详解

A comprehensive visual and technical reference for port-based network access control using EAP-TLS mutual certificate authentication — with Cisco ISE and industrial AGV deployments. 基于端口的网络访问控制 EAP-TLS 双向证书认证的完整可视化技术参考 — 涵盖 Cisco ISE 与工业 AGV 部署场景。

IEEE 802.1X-2020 RFC 5216 (EAP-TLS) RFC 9190 (EAP-TLS 1.3) Cisco ISE TLS 1.2 / 1.3

🔎 Overview 🔎 概述

802.1X is the IEEE standard for Port-Based Network Access Control (IEEE 802.1X-2020, Clause 6). It defines an architecture comprising three roles: the Supplicant (the endpoint requesting access, e.g., an AGV), the Authenticator (the network device enforcing access, e.g., an AP or switch), and the Authentication Server (the policy engine, e.g., Cisco ISE). Communication between the Supplicant and Authenticator uses EAPOL (EAP over LAN, EtherType 0x888E), while the Authenticator relays EAP messages to the Authentication Server via RADIUS (RFC 2865 / RFC 3579).

802.1X 是 IEEE 制定的基于端口的网络访问控制标准（IEEE 802.1X-2020，第6章）。它定义了三个角色：请求者（Supplicant）（请求接入的终端，如 AGV）、认证者（Authenticator）（执行访问控制的网络设备，如 AP 或交换机）和认证服务器（Authentication Server）（策略引擎，如 Cisco ISE）。请求者与认证者之间使用 EAPOL（EAP over LAN，以太类型 0x888E）通信，认证者通过 RADIUS（RFC 2865 / RFC 3579）将 EAP 消息中继到认证服务器。

EAP-TLS (EAP Type 13, defined in RFC 5216 and updated by RFC 9190 for TLS 1.3) is the gold-standard EAP method. It provides mutual authentication using X.509 certificates on both sides — no passwords are transmitted. The TLS handshake establishes a secure tunnel, derives keying material (MSK and EMSK), and upon success, the Authenticator opens the controlled port, granting the Supplicant network access.

EAP-TLS（EAP 类型 13，由 RFC 5216 定义，RFC 9190 更新以支持 TLS 1.3）是业界公认的最高安全级别 EAP 方法。它使用双方的 X.509 证书进行双向认证——不传输密码。TLS 握手建立安全隧道，派生密钥材料（MSK 和 EMSK），认证成功后，认证者开放受控端口，授予请求者网络访问权限。

🏭 Industrial Context: AGV Deployments
🏭 工业场景：AGV 部署

Automated Guided Vehicles (AGVs) in warehouses and factories require secure, seamless wireless authentication. EAP-TLS with Cisco ISE ensures that each AGV is uniquely identified by its device certificate, enabling fine-grained authorization policies (VLAN assignment, dACL, SGT) while supporting fast roaming across APs.

仓库和工厂中的自动导引车（AGV）需要安全、无缝的无线认证。使用 Cisco ISE 的 EAP-TLS 确保每台 AGV 通过其设备证书被唯一识别，支持细粒度授权策略（VLAN 分配、dACL、SGT），同时支持跨 AP 快速漫游。

1

Phase 1 — 802.11 Association & EAPOL Start 阶段 1 — 802.11 关联与 EAPOL 启动

IEEE 802.1X-2020 §11.3, §6.3.2 | IEEE 802.11-2020 §12.3 IEEE 802.1X-2020 §11.3, §6.3.2 | IEEE 802.11-2020 §12.3

📡 802.11 Open System Authentication & Association 802.11 开放系统认证与关联

Before 802.1X begins, the AGV (wireless supplicant) must first establish a Layer-2 802.11 association with the Access Point (AP). This is a prerequisite — the EAPOL exchange runs on top of the 802.11 association. With WPA2/WPA3-Enterprise, the AP advertises an RSN Information Element in its Beacons/Probe Responses indicating that 802.1X authentication is required. The association process is:

在 802.1X 开始之前，AGV（无线请求者）必须首先与接入点（AP）建立第 2 层 802.11 关联。这是前提条件——EAPOL 交换在 802.11 关联之上运行。在 WPA2/WPA3-Enterprise 模式下，AP 在其 Beacon/Probe Response 帧中通告 RSN 信息元素，表明需要 802.1X 认证。关联过程如下：

  1. 1
    AGV → AP
    Probe Request
    Probe Request（探测请求）

    The AGV scans channels and sends a Probe Request to discover available networks (SSIDs). In an AGV deployment, the SSID is typically pre-configured.

    AGV 扫描信道并发送 Probe Request 以发现可用网络（SSID）。在 AGV 部署中，SSID 通常已预配置。

  2. 2
    AP → AGV
    Probe Response
    Probe Response（探测响应）

    AP responds with supported rates, RSN IE (cipher suites: AES-CCMP / AES-GCMP, AKM: 802.1X), and capability information.

    AP 回复支持的速率、RSN IE（加密套件：AES-CCMP / AES-GCMP，AKM：802.1X）和能力信息。

  3. 3
    AGV → AP
    802.11 Authentication (Open System)
    802.11 认证（开放系统）

    A simple two-frame exchange (Authentication Request → Authentication Response, status=0). This is not the actual security authentication — that happens via 802.1X/EAP.

    简单的两帧交换（认证请求 → 认证响应，status=0）。这不是真正的安全认证——安全认证通过 802.1X/EAP 进行。

  4. 4
    AGV ↔ AP
    Association Request / Response
    关联请求 / 关联响应

    AGV sends Association Request with its RSN IE (matching cipher/AKM), and AP responds with Association Response (Association ID assigned). At this point, the AGV has a Layer-2 link but the controlled port remains blocked — no data traffic is permitted until 802.1X succeeds.

    AGV 发送关联请求及其 RSN IE（匹配加密/AKM），AP 回复关联响应（分配关联 ID）。此时，AGV 拥有第 2 层链路，但受控端口仍然处于阻塞状态——在 802.1X 成功之前不允许数据流量通过。

🚀 EAPOL-Start EAPOL-Start（EAPOL 启动）

Once associated, the AGV initiates the 802.1X authentication by sending an EAPOL-Start frame on the uncontrolled port. Per IEEE 802.1X-2020 §11.3, the EAPOL frame format is:

关联完成后，AGV 通过在非受控端口上发送 EAPOL-Start 帧来启动 802.1X 认证。根据 IEEE 802.1X-2020 §11.3，EAPOL 帧格式如下：

Field字段 Size大小 Value值 Description说明
Destination MAC 6 B 01:80:C2:00:00:03 IEEE 802.1X PAE group address (IEEE 802.1X-2020 §11.1.1) IEEE 802.1X PAE 组播地址（IEEE 802.1X-2020 §11.1.1）
EtherType 2 B 0x888E EAPOL EtherType identifier EAPOL 以太类型标识
Protocol Version 1 B 0x03 802.1X-2020 (version 3) 802.1X-2020（版本 3）
Packet Type 1 B 0x01 EAPOL-Start EAPOL-Start（启动）
Packet Body Length 2 B 0x0000 No body — Start is a signal frame 无消息体——Start 为信号帧
📌 Controlled vs. Uncontrolled Port
📌 受控端口与非受控端口

IEEE 802.1X-2020 §6.3.2 defines the PAE (Port Access Entity) as having two virtual access points: the Uncontrolled Port (always open, carries only EAPOL/MKA traffic) and the Controlled Port (initially blocked, opened only after successful authentication). This separation ensures that authentication frames can always transit even when the network is "locked."

IEEE 802.1X-2020 §6.3.2 定义 PAE（端口访问实体）具有两个虚拟接入点：非受控端口（始终开放，仅承载 EAPOL/MKA 流量）和受控端口（初始阻塞，仅在认证成功后开放）。这种分离确保即使网络被"锁定"，认证帧也能始终通过。

Authenticator behavior: Upon receiving EAPOL-Start, the Authenticator's PACP (Port Access Control Protocol) state machine transitions from DISCONNECTED → CONNECTING and sends an EAP-Request/Identity to the Supplicant (IEEE 802.1X-2020 §8.2). Alternatively, the Authenticator may proactively send an EAP-Request/Identity upon detecting link-up, without waiting for EAPOL-Start.

认证者行为：收到 EAPOL-Start 后，认证者的 PACP（端口访问控制协议）状态机从 DISCONNECTED → CONNECTING 转换，并向请求者发送 EAP-Request/Identity（IEEE 802.1X-2020 §8.2）。另外，认证者也可能在检测到链路连接后主动发送 EAP-Request/Identity，无需等待 EAPOL-Start。

2

Phase 2 — EAP Identity Exchange 阶段 2 — EAP 身份交换

RFC 3748 §5.1 | RFC 5216 §2.1.1 | IEEE 802.1X-2020 §8.2 RFC 3748 §5.1 | RFC 5216 §2.1.1 | IEEE 802.1X-2020 §8.2

🆔 EAP-Request/Identity & EAP-Response/Identity EAP-Request/Identity 与 EAP-Response/Identity

The identity exchange is the first EAP method-independent step. It allows the Authentication Server to learn who is requesting access. The exchange involves two messages:

身份交换是第一个与 EAP 方法无关的步骤。它允许认证服务器了解谁正在请求访问。交换涉及两条消息：

  1. 1
    AP/Switch → AGV (EAPOL)
    EAP-Request/Identity

    The Authenticator sends an EAP-Request with Type=1 (Identity). EAP packet structure: Code=1 (Request), Identifier=N, Length, Type=1 (Identity). The Identifier field is used for retransmission matching (RFC 3748 §4.1).

    认证者发送类型为 1（Identity）的 EAP-Request。EAP 包结构：Code=1（请求），Identifier=N，Length，Type=1（Identity）。Identifier 字段用于重传匹配（RFC 3748 §4.1）。

  2. 2
    AGV → AP/Switch (EAPOL) → Cisco ISE (RADIUS)
    EAP-Response/Identity

    The AGV replies with its identity string. In an EAP-TLS deployment, this is typically the Common Name (CN) or Subject Alternative Name (SAN) from the device certificate, e.g., agv-0042@factory.example.com. The Authenticator encapsulates this EAP-Response inside a RADIUS Access-Request message (RADIUS attribute type 79: EAP-Message) and forwards it to Cisco ISE.

    AGV 回复其身份字符串。在 EAP-TLS 部署中，通常是设备证书中的通用名称（CN）或主体备用名称（SAN），例如 agv-0042@factory.example.com。认证者将此 EAP-Response 封装在 RADIUS Access-Request 消息中（RADIUS 属性类型 79：EAP-Message）并转发给 Cisco ISE。

🔒 Identity Privacy & Anonymous NAI 身份隐私与匿名 NAI

Sending the real identity in cleartext during Phase 2 is a privacy concern — a passive eavesdropper can learn the Supplicant's identity. Two mitigations exist:

在阶段 2 以明文发送真实身份存在隐私问题——被动窃听者可以获知请求者的身份。有两种缓解方式：

Approach方式 TLS VersionTLS 版本 Description说明 Reference参考
Anonymous NAI TLS 1.2 Supplicant sends an anonymous outer identity like anonymous@factory.example.com. The real identity is conveyed inside the TLS tunnel via the client certificate. Configured on the supplicant. 请求者发送匿名外部身份，如 anonymous@factory.example.com。真实身份通过 TLS 隧道内的客户端证书传递。在请求者上配置。 RFC 5216 §2.1.4
TLS 1.3 Encrypted Certs TLS 1.3 In TLS 1.3, all certificates are sent encrypted (after ServerHello). The peer identity is never disclosed to eavesdroppers. This is a significant privacy improvement over TLS 1.2. An anonymous NAI is still RECOMMENDED for the outer identity. 在 TLS 1.3 中，所有证书在 ServerHello 之后加密发送。对等方的身份永远不会被窃听者看到。这是相对于 TLS 1.2 的重大隐私改进。外部身份仍然建议使用匿名 NAI。 RFC 9190 §2.1.4
⚠️ RADIUS Relay Mechanics
⚠️ RADIUS 中继机制

The Authenticator (AP/Switch) acts as a pass-through for EAP messages. It does NOT interpret EAP methods — it simply wraps EAP payloads into RADIUS EAP-Message attributes (Type 79, RFC 3579 §3.1) within Access-Request packets and unwraps them from Access-Challenge / Access-Accept / Access-Reject responses from ISE. The RADIUS shared secret protects the RADIUS transport, but the EAP payload inside is opaque to the Authenticator.

认证者（AP/交换机）充当 EAP 消息的透传角色。它不解析 EAP 方法——只是将 EAP 载荷封装到 RADIUS EAP-Message 属性（类型 79，RFC 3579 §3.1）中的 Access-Request 包中，并从 ISE 的 Access-Challenge / Access-Accept / Access-Reject 响应中解封装。RADIUS 共享密钥保护 RADIUS 传输，但其中的 EAP 载荷对认证者来说是不透明的。

⚡ EAP-TLS Method Selection EAP-TLS 方法选择

Upon receiving the EAP-Response/Identity, Cisco ISE looks up its authentication policy to determine which EAP method to use. When the policy specifies EAP-TLS, ISE responds with a RADIUS Access-Challenge containing an EAP-Request with Type=13 (EAP-TLS) and the TLS Start flag set (S=1). This transitions the conversation from the generic EAP identity phase into the TLS handshake (Phase 3).

收到 EAP-Response/Identity 后，Cisco ISE 查找其认证策略以确定使用哪种 EAP 方法。当策略指定 EAP-TLS 时，ISE 以 RADIUS Access-Challenge 响应，其中包含一个类型为 13（EAP-TLS）、且设置了 TLS Start 标志（S=1）的 EAP-Request。这将会话从通用 EAP 身份阶段过渡到 TLS 握手（阶段 3）。

EAP-TLS FlagEAP-TLS 标志 Bit位 Meaning含义 Reference参考
L (Length included) Bit 7 TLS Message Length field is present (used when message is fragmented) TLS 消息长度字段存在（用于消息分片时） RFC 5216 §3.1
M (More fragments) Bit 6 More TLS fragments follow — recipient must wait for complete message 后续还有 TLS 分片——接收方需等待完整消息 RFC 5216 §3.1
S (Start) Bit 5 EAP-TLS Start — sent only by the server to initiate TLS handshake EAP-TLS 启动——仅由服务器发送以启动 TLS 握手 RFC 5216 §3.1
3

Phase 3 — TLS 1.2 Mutual Authentication Handshake 阶段 3 — TLS 1.2 双向认证握手

RFC 5216 §2.1.1, §3 | RFC 9190 §2.1.1

This is the core of EAP-TLS: a full TLS handshake carried inside EAP messages, providing mutual certificate-based authentication between the supplicant (AGV) and the authentication server (Cisco ISE). Unlike web HTTPS where only the server is authenticated, EAP-TLS requires both sides to present X.509 certificates. The handshake follows RFC 5246 (TLS 1.2) encapsulated per RFC 5216 §3.

这是 EAP-TLS 的核心：在 EAP 消息内部承载完整的 TLS 握手，实现请求方（AGV）与认证服务器（Cisco ISE）之间 基于证书的双向认证。与 Web HTTPS 仅验证服务器不同，EAP-TLS 要求双方都出示 X.509 证书。 握手遵循 RFC 5246（TLS 1.2），并按 RFC 5216 §3 进行封装。

3a. ClientHello 3a. ClientHello（客户端问候）

→
Supplicant → Authenticator → RADIUS (ISE) 请求方 → 认证者 → RADIUS（ISE）

The supplicant constructs a TLS ClientHello and sends it inside an EAP-Response/EAP-TLS message (Type 13). The EAP-TLS S (Start) bit is NOT set on this message — only the server sets the S bit in its initial EAP-Request/EAP-TLS. The authenticator relays this in a RADIUS Access-Request (EAP-Message attribute, Type 79).

请求方构造 TLS ClientHello，并封装在 EAP-Response/EAP-TLS（Type 13）消息中发送。 此消息中 EAP-TLS 的 S（Start）位不置位——仅服务器在初始 EAP-Request/EAP-TLS 中设置 S 位。 认证者将其转发至 RADIUS Access-Request（EAP-Message 属性，Type 79）。

ClientHello Key Fields ClientHello 关键字段
Field字段 Value / Description值 / 描述
ProtocolVersion TLS 1.2 = 0x0303 TLS 1.2 = 0x0303
Random 32 bytes — 4-byte timestamp + 28-byte cryptographic random (used in key derivation) 32 字节 — 4 字节时间戳 + 28 字节加密随机数（用于密钥派生）
SessionID Empty (new session) or cached value (TLS session resumption / abbreviated handshake) 空（新会话）或缓存值（TLS 会话恢复 / 简短握手）
CipherSuites Ordered list of supported cipher suites. RFC 5216 §2.4 mandates at least TLS_RSA_WITH_3DES_EDE_CBC_SHA; modern deployments prefer AES-GCM suites. 按优先级排列的支持密码套件列表。RFC 5216 §2.4 要求至少支持 TLS_RSA_WITH_3DES_EDE_CBC_SHA；现代部署推荐 AES-GCM 套件。
CompressionMethods null (0x00) — compression MUST NOT be used in EAP-TLS per RFC 5216 §5.3 null (0x00) — 根据 RFC 5216 §5.3，EAP-TLS 中不得使用压缩
Extensions signature_algorithms, supported_groups (for ECDHE), server_name (SNI — optional), status_request (OCSP stapling) signature_algorithms、supported_groups（用于 ECDHE）、 server_name（SNI — 可选）、status_request（OCSP 装订）

3b. ServerHello + Certificate + CertificateRequest + ServerHelloDone 3b. ServerHello + Certificate + CertificateRequest + ServerHelloDone

←
RADIUS (ISE) → Authenticator → Supplicant RADIUS（ISE）→ 认证者 → 请求方

Cisco ISE responds with multiple TLS handshake messages, typically bundled in a single TLS record flight and carried inside one or more RADIUS Access-Challenge packets (each containing an EAP-Message attribute). Due to the large size of server certificates, EAP-TLS fragmentation is almost always required here (see §3h below).

Cisco ISE 回复多个 TLS 握手消息，通常打包在单个 TLS 记录飞行中，通过一个或多个 RADIUS Access-Challenge 报文承载（每个包含 EAP-Message 属性）。 由于服务器证书体积较大，此处几乎总是需要 EAP-TLS 分片（参见下文 §3h）。

Server Flight Messages 服务器飞行消息
TLS MessageTLS 消息 Description描述
ServerHello Selects TLS version (0x0303), cipher suite, compression method (null), and provides 32-byte server Random. Also contains a SessionID for potential future resumption. 选择 TLS 版本（0x0303）、密码套件、压缩方法（null），并提供 32 字节服务器 Random。还包含 SessionID 用于未来的会话恢复。
Certificate ISE's X.509 certificate chain: ISE server certificate → Intermediate CA → Root CA. The supplicant must validate this chain (see §3c). ISE 的 X.509 证书链：ISE 服务器证书 → 中间 CA → 根 CA。 请求方必须验证此证书链（参见 §3c）。
ServerKeyExchange Only present for DHE/ECDHE cipher suites. Contains the server's ephemeral DH/ECDH public key, signed with the server's private key. Not sent for RSA key exchange. 仅在 DHE/ECDHE 密码套件中存在。包含服务器的临时 DH/ECDH 公钥， 由服务器私钥签名。RSA 密钥交换时不发送。
CertificateRequest Critical for EAP-TLS: requests the client (AGV) certificate. Specifies acceptable certificate_types (RSA, ECDSA), supported_signature_algorithms, and optionally certificate_authorities (list of acceptable CA DNs). EAP-TLS 的关键消息：请求客户端（AGV）证书。指定可接受的 certificate_types（RSA、ECDSA）、supported_signature_algorithms 以及可选的 certificate_authorities（可接受的 CA DN 列表）。
ServerHelloDone Signals the end of the server's hello-phase messages. The supplicant can now process all received messages and prepare its response flight. 标志服务器问候阶段消息结束。请求方现在可以处理所有收到的消息并准备其响应飞行。

3c. Server Certificate Chain Validation (by Supplicant) 3c. 服务器证书链验证（由请求方执行）

Before proceeding, the supplicant (AGV's 802.1X software) MUST validate the ISE server certificate chain. This is a critical security step — failure to properly validate opens the door to man-in-the-middle attacks. The validation follows standard X.509 path validation (RFC 5280).

在继续之前，请求方（AGV 的 802.1X 软件）必须验证 ISE 服务器证书链。这是关键的安全步骤—— 验证不当将导致中间人攻击风险。验证遵循标准 X.509 路径验证（RFC 5280）。

1
Chain Building 证书链构建

Build the chain: ISE Server Cert → Intermediate CA → Root CA. Each certificate's Issuer field must match the next certificate's Subject, and the Authority Key Identifier must match the issuer's Subject Key Identifier.

构建证书链：ISE 服务器证书 → 中间 CA → 根 CA。 每个证书的 Issuer 字段必须与下一个证书的 Subject 匹配， Authority Key Identifier 必须与签发者的 Subject Key Identifier 匹配。

2
Root CA Trust Anchor 根 CA 信任锚

The root CA certificate must exist in the supplicant's local trust store. In industrial AGV deployments, this is typically provisioned during initial device setup or via MDM/SCEP enrollment.

根 CA 证书必须存在于请求方的本地信任存储中。在工业 AGV 部署中，通常在初始设备配置或通过 MDM/SCEP 注册时预置。

3
Signature Verification 签名验证

Verify each certificate's digital signature using the issuer's public key. The Root CA is self-signed (its own public key verifies its own signature).

使用签发者的公钥验证每个证书的数字签名。根 CA 是自签名的（其自身公钥验证其自身签名）。

4
Validity Period & Revocation Check 有效期与吊销检查

Check that each certificate's notBefore ≤ current time ≤ notAfter. Perform revocation checking via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol). OCSP stapling (status_request extension) reduces latency.

检查每个证书的 notBefore ≤ 当前时间 ≤ notAfter。 通过 CRL（证书吊销列表）或 OCSP（在线证书状态协议）执行吊销检查。 OCSP 装订（status_request 扩展）可降低延迟。

5
Server Identity Verification 服务器身份验证

Optionally verify the ISE server's identity by checking the certificate's Subject CN or Subject Alternative Name (SAN) against a configured expected server name. This prevents rogue RADIUS server attacks.

可选地验证 ISE 服务器身份：检查证书的 Subject CN 或 Subject Alternative Name (SAN) 是否与配置的预期服务器名称匹配。 此步骤可防止恶意 RADIUS 服务器攻击。

⚠ Security Warning: Many industrial supplicants have a "Do not validate server certificate" option. This MUST be disabled in production. Without server certificate validation, an attacker can present a rogue RADIUS server with a self-signed certificate and capture client credentials (though in EAP-TLS this means capturing the client certificate exchange, which still requires the private key). However, disabling validation also enables TLS downgrade attacks. ⚠ 安全警告：许多工业请求方有"不验证服务器证书"选项。在生产环境中必须禁用此选项。 如果不验证服务器证书，攻击者可使用自签名证书的恶意 RADIUS 服务器捕获客户端凭据（虽然在 EAP-TLS 中这意味着 捕获客户端证书交换，仍需私钥）。此外，禁用验证还会导致 TLS 降级攻击风险。

3d. Client Certificate + ClientKeyExchange + CertificateVerify + ChangeCipherSpec + Finished 3d. 客户端证书 + ClientKeyExchange + CertificateVerify + ChangeCipherSpec + Finished

→
Supplicant → Authenticator → RADIUS (ISE) 请求方 → 认证者 → RADIUS（ISE）

The supplicant responds with its own flight of TLS messages, again carried inside EAP-Response/EAP-TLS and relayed via RADIUS Access-Request. This flight is also large (contains the client certificate chain) and typically requires fragmentation.

请求方回复自己的 TLS 消息飞行，同样封装在 EAP-Response/EAP-TLS 中， 通过 RADIUS Access-Request 转发。此飞行也较大（包含客户端证书链），通常需要分片。

Client Flight Messages 客户端飞行消息
TLS MessageTLS 消息 Description描述
Certificate The AGV's X.509 client certificate chain. In industrial deployments, typically: AGV device cert (CN = serial number or MAC) → Intermediate CA → Root CA. The Root CA should be the same PKI hierarchy trusted by ISE, or a cross-certified CA. AGV 的 X.509 客户端证书链。在工业部署中通常为： AGV 设备证书（CN = 序列号或 MAC）→ 中间 CA → 根 CA。根 CA 应与 ISE 信任的 PKI 层次结构相同， 或为交叉认证的 CA。
ClientKeyExchange For RSA: contains the Pre-Master Secret (PMS) — 48 bytes, encrypted with the server's public key. For ECDHE: contains the client's ephemeral ECDH public key. The PMS is then computed as the shared ECDH secret. 对于 RSA：包含预主密钥（PMS）— 48 字节， 用服务器公钥加密。对于 ECDHE：包含客户端的临时 ECDH 公钥。 PMS 则计算为共享的 ECDH 密钥。
CertificateVerify Proves possession of the private key: the supplicant signs a hash of all handshake messages exchanged so far using its private key. ISE verifies this signature with the client certificate's public key. This is the cryptographic proof of identity. 证明私钥持有权：请求方使用其私钥对迄今为止交换的所有握手消息的哈希进行签名。 ISE 使用客户端证书的公钥验证此签名。这是身份的密码学证明。
ChangeCipherSpec Signals that all subsequent messages from the client will be encrypted using the negotiated cipher suite and keys derived from the master secret. (This is technically a protocol message, not a handshake message.) 指示客户端后续所有消息将使用协商的密码套件和从主密钥派生的密钥加密。 （这在技术上是协议消息，不是握手消息。）
Finished The first encrypted message. Contains a verify_data value — a PRF hash over the master secret and all handshake messages. ISE decrypts and verifies this to confirm the handshake integrity and that both sides derived the same keys. 第一条加密消息。包含 verify_data 值——对主密钥和所有握手消息 的 PRF 哈希。ISE 解密并验证此值以确认握手完整性及双方派生了相同的密钥。

3e. Client Certificate Validation (by Cisco ISE) 3e. 客户端证书验证（由 Cisco ISE 执行）

Upon receiving the client's certificate flight, Cisco ISE performs comprehensive validation before completing the handshake. ISE's certificate validation is configured under Administration → Certificates → Certificate Store and Policy → Authentication Policy.

收到客户端证书飞行后，Cisco ISE 在完成握手前执行全面验证。ISE 的证书验证在 Administration → Certificates → Certificate Store 和 Policy → Authentication Policy 下配置。

1
Certificate Chain Validation 证书链验证

Same chain-building and signature verification as §3c, but now ISE validates the client certificate chain against its trusted certificate store.

与 §3c 相同的证书链构建和签名验证，但此处 ISE 根据其信任的证书存储验证客户端证书链。

2
CN / SAN Identity Check CN / SAN 身份检查

ISE extracts the client identity from the certificate's Subject CN, Subject Alternative Name (e.g., DNS name, email, or custom OID), or other configurable fields. This identity is matched against ISE's identity sources (internal database, LDAP, Active Directory) for authorization policy lookup.

ISE 从证书的 Subject CN、Subject Alternative Name （如 DNS 名称、邮箱或自定义 OID）或其他可配置字段中提取客户端身份。此身份与 ISE 的身份源 （内部数据库、LDAP、Active Directory）匹配以进行授权策略查找。

3
Validity Period Check 有效期检查

Verify notBefore ≤ current time ≤ notAfter for all certificates in the chain. Expired or not-yet-valid certificates cause authentication failure.

验证链中所有证书的 notBefore ≤ 当前时间 ≤ notAfter。 过期或尚未生效的证书将导致认证失败。

4
CRL / OCSP Revocation Check CRL / OCSP 吊销检查

ISE checks whether the client certificate has been revoked. Configured under Administration → Certificates → OCSP Client Profile or CRL distribution points. If the revocation check fails or the certificate is revoked, ISE sends Access-Reject with an EAP-Failure.

ISE 检查客户端证书是否已被吊销。在 Administration → Certificates → OCSP Client Profile 或 CRL 分发点下配置。如果吊销检查失败或证书已吊销，ISE 发送 Access-Reject 及 EAP-Failure。

5
CertificateVerify Signature Validation CertificateVerify 签名验证

ISE verifies the CertificateVerify message signature using the client certificate's public key. This cryptographically proves the supplicant possesses the corresponding private key — the definitive proof of identity in EAP-TLS.

ISE 使用客户端证书的公钥验证 CertificateVerify 消息签名。这从密码学上证明 请求方持有对应的私钥——这是 EAP-TLS 中身份的最终证明。

3f. Server ChangeCipherSpec + Finished → TLS Tunnel Established 3f. 服务器 ChangeCipherSpec + Finished → TLS 隧道建立

←
RADIUS (ISE) → Authenticator → Supplicant RADIUS（ISE）→ 认证者 → 请求方

If all validations pass, ISE sends its own ChangeCipherSpec and encrypted Finished message (containing verify_data). The supplicant verifies this to confirm the server also derived the same keys. At this point, the TLS tunnel is fully established and both sides have been mutually authenticated.

如果所有验证通过，ISE 发送自己的 ChangeCipherSpec 和加密的 Finished 消息（包含 verify_data）。请求方验证此消息以确认 服务器也派生了相同的密钥。此时，TLS 隧道完全建立，双方已完成双向认证。

ℹ Note: In EAP-TLS (unlike HTTPS), no application data is exchanged over the TLS tunnel in TLS 1.2. The tunnel is established solely for the purpose of mutual authentication and key derivation. Once the handshake completes, the TLS session is used only to derive keying material (MSK/EMSK). In TLS 1.3, a single 0x00 byte of application data is sent as a protected success indication (RFC 9190 §2.5). ℹ 说明：在 EAP-TLS 中（与 HTTPS 不同），TLS 1.2 不会在 TLS 隧道上交换应用数据。 隧道的建立仅用于双向认证和密钥派生。握手完成后，TLS 会话仅用于派生密钥材料（MSK/EMSK）。 在 TLS 1.3 中，会发送一个 0x00 字节的应用数据作为受保护的成功指示（RFC 9190 §2.5）。

3g. Key Derivation — MSK & EMSK 3g. 密钥派生 — MSK 与 EMSK

After the TLS handshake completes, EAP-TLS derives keying material from the TLS master secret. These keys are NOT the TLS session keys — they are additional key material exported from the TLS session for use by the 802.1X/802.11 infrastructure.

TLS 握手完成后，EAP-TLS 从 TLS 主密钥派生密钥材料。这些密钥不是 TLS 会话密钥—— 它们是从 TLS 会话中导出的额外密钥材料，供 802.1X/802.11 基础设施使用。

TLS 1.2 Key Derivation (RFC 5216 §2.3) TLS 1.2 密钥派生（RFC 5216 §2.3）

Key_Material = TLS-PRF-128(master_secret, "client EAP encryption", client.random || server.random) MSK = Key_Material[0..63] // First 64 octets (512 bits) EMSK = Key_Material[64..127] // Next 64 octets (512 bits) Session-Id = 0x0D || client.random || server.random // 0x0D = EAP-TLS Type code (13)
EAP-TLS 1.2 Derived Keys EAP-TLS 1.2 派生密钥
Key密钥 Size大小 Purpose用途
MSK (Master Session Key)（主会话密钥） 64 bytes字节 Sent from RADIUS server to authenticator in MS-MPPE-Recv-Key and MS-MPPE-Send-Key attributes within the Access-Accept. Used as the PMK (Pairwise Master Key) in 802.11i — input to the 4-Way Handshake to derive PTK (Pairwise Transient Key) for wireless encryption. 通过 Access-Accept 中的 MS-MPPE-Recv-Key 和 MS-MPPE-Send-Key 属性从 RADIUS 服务器发送至认证者。 在 802.11i 中用作 PMK（成对主密钥）——作为四次握手的输入以派生 PTK（成对临时密钥）用于无线加密。
EMSK (Extended MSK)（扩展主会话密钥） 64 bytes字节 Reserved for future use and additional key derivation. Not sent to the authenticator. Can be used for domain-specific keys per RFC 5295. 保留用于未来使用和额外密钥派生。不发送至认证者。可根据 RFC 5295 用于特定域密钥。

TLS 1.3 Key Derivation (RFC 9190 §2.3) TLS 1.3 密钥派生（RFC 9190 §2.3）

// TLS 1.3 uses TLS-Exporter (RFC 8446 §7.5) MSK = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) // 128 octets → first 64 = MSK, next 64 = EMSK // Actually: Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) MSK = Key_Material[0..63] EMSK = Key_Material[64..127] Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64) Session-Id = 0x0D || Method-Id
ℹ TLS 1.3 Key Derivation Difference: TLS 1.3 does not use the TLS-PRF function. Instead, it uses TLS-Exporter (RFC 8446 §7.5) with specific labels. The client.random and server.random values are NOT directly used in the exporter; the TLS 1.3 key schedule (HKDF-based) provides the exporter master secret internally. The Session-Id also differs — it uses an exported Method-Id rather than concatenated randoms. ℹ TLS 1.3 密钥派生差异：TLS 1.3 不使用 TLS-PRF 函数， 而是使用 TLS-Exporter（RFC 8446 §7.5）及特定标签。 client.random 和 server.random 值不直接用于导出器； TLS 1.3 密钥调度（基于 HKDF）内部提供导出器主密钥。 Session-Id 也不同——使用导出的 Method-Id 而非拼接的随机数。

3h. Cipher Suite Recommendations 3h. 密码套件推荐

Recommended Cipher Suites for EAP-TLS EAP-TLS 推荐密码套件
TLS VersionTLS 版本 Cipher Suite密码套件 Notes备注
TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Preferred — PFS via ECDHE, AEAD encryption 推荐 — 通过 ECDHE 实现前向保密，AEAD 加密
TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Preferred for ECDSA certificates — strongest PFS + AEAD ECDSA 证书推荐 — 最强前向保密 + AEAD
TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Good balance of security and performance 安全性与性能的良好平衡
TLS 1.2 TLS_RSA_WITH_3DES_EDE_CBC_SHA RFC 5216 §2.4 mandatory minimum — NOT recommended for production; no PFS, weak cipher RFC 5216 §2.4 强制最低要求 — 不推荐用于生产；无前向保密，弱密码
TLS 1.3 TLS_AES_256_GCM_SHA384 RFC 8446 §9 mandatory — all TLS 1.3 suites have PFS (ECDHE/DHE built-in) RFC 8446 §9 强制 — 所有 TLS 1.3 套件内置前向保密（ECDHE/DHE）
TLS 1.3 TLS_AES_128_GCM_SHA256 RFC 8446 §9 mandatory — good for resource-constrained AGV devices RFC 8446 §9 强制 — 适用于资源受限的 AGV 设备
TLS 1.3 TLS_CHACHA20_POLY1305_SHA256 Excellent for software-only implementations (no AES-NI needed) 适合纯软件实现（无需 AES-NI 硬件加速）

3i. TLS 1.3 Handshake Differences (RFC 9190) 3i. TLS 1.3 握手差异（RFC 9190）

RFC 9190 updates EAP-TLS for TLS 1.3, introducing significant changes to the handshake flow. The fundamental authentication model remains the same (mutual certificate authentication), but the handshake mechanics differ substantially.

RFC 9190 将 EAP-TLS 更新为支持 TLS 1.3，引入了握手流程的重大变化。 基本认证模型保持不变（双向证书认证），但握手机制有显著差异。

TLS 1.2 vs TLS 1.3 in EAP-TLS — Key Differences EAP-TLS 中 TLS 1.2 与 TLS 1.3 的关键差异
Aspect方面 TLS 1.2 (RFC 5216) TLS 1.3 (RFC 9190)
Handshake Round Trips握手往返次数 2-RTT 1-RTT (server flight combines Hello + encrypted extensions + certificate) 1-RTT（服务器飞行合并 Hello + 加密扩展 + 证书）
Certificate Encryption证书加密 Certificates sent in cleartext 证书以明文发送 Certificates sent encrypted (after ServerHello + key exchange) 证书加密发送（在 ServerHello + 密钥交换之后）
Identity Privacy身份隐私 Client certificate visible to eavesdroppers; requires Anonymous NAI workaround 客户端证书对窃听者可见；需要匿名 NAI 变通方案 Client certificate encrypted — native identity privacy 客户端证书加密——原生身份隐私保护
CertificateRequest Sent in cleartext as part of server's first flight 以明文发送，作为服务器第一飞行的一部分 Sent encrypted after ServerHello 在 ServerHello 之后加密发送
Key Exchange密钥交换 RSA, DHE, or ECDHE (configurable) RSA、DHE 或 ECDHE（可配置） ECDHE or DHE only — PFS is mandatory 仅 ECDHE 或 DHE——前向保密为强制要求
Key Derivation密钥派生 TLS-PRF TLS-Exporter (HKDF-based)
Session Resumption会话恢复 Session ID or Session Ticket Session ID 或 Session Ticket PSK-based resumption (NewSessionTicket). RFC 9190 §5.7 prohibits resumption for EAP-TLS 1.3 — each authentication MUST be a full handshake. 基于 PSK 的恢复（NewSessionTicket）。RFC 9190 §5.7 禁止 EAP-TLS 1.3 的会话恢复——每次认证必须是完整握手。
Success Indication成功指示 Empty EAP-TLS response (no TLS data) after server Finished 服务器 Finished 后发送空 EAP-TLS 响应（无 TLS 数据） Server sends protected 0x00 application data; client sends empty response. This confirms TLS 1.3 tunnel intact (RFC 9190 §2.5). 服务器发送受保护的 0x00 应用数据；客户端发送空响应。 这确认 TLS 1.3 隧道完整（RFC 9190 §2.5）。
ChangeCipherSpec Explicit protocol message before Finished 在 Finished 之前的显式协议消息 Removed in TLS 1.3 (may appear as compatibility middlebox artifact) 在 TLS 1.3 中已移除（可能作为兼容性中间盒工件出现）
⚠ RFC 9190 §5.7 — No Resumption: Unlike web TLS 1.3, EAP-TLS 1.3 explicitly prohibits TLS session resumption. Servers MUST NOT send NewSessionTicket messages, and clients MUST NOT offer PSK-based resumption in ClientHello. Each EAP-TLS authentication MUST perform a full handshake. This is because EAP-TLS resumption is handled at the EAP layer (PMKSA caching, not TLS layer resumption). ⚠ RFC 9190 §5.7 — 禁止恢复：与 Web TLS 1.3 不同，EAP-TLS 1.3 明确 禁止 TLS 会话恢复。服务器不得发送 NewSessionTicket 消息， 客户端不得在 ClientHello 中提供基于 PSK 的恢复。每次 EAP-TLS 认证必须执行完整握手。 这是因为 EAP-TLS 的恢复在 EAP 层处理（PMKSA 缓存，而非 TLS 层恢复）。

3j. EAP-TLS Fragmentation (RFC 5216 §2.1.5) 3j. EAP-TLS 分片（RFC 5216 §2.1.5）

TLS handshake messages — especially certificate chains — often exceed the EAP MTU (typically 1020 bytes for RADIUS, limited by the 4096-byte RADIUS packet size minus overhead). EAP-TLS handles this with its own fragmentation mechanism, independent of IP fragmentation.

TLS 握手消息——尤其是证书链——通常超过 EAP MTU（对于 RADIUS 通常为 1020 字节， 受限于 4096 字节 RADIUS 包大小减去开销）。EAP-TLS 通过自己的分片机制处理此问题，独立于 IP 分片。

EAP-TLS Fragmentation Flags (RFC 5216 §3.1) EAP-TLS 分片标志（RFC 5216 §3.1）
Flag标志 Bit位 Meaning含义
L (Length included) Bit 7 Set on the first fragment — indicates the 4-byte TLS Message Length field is present, giving the total unfragmented TLS data length. 在第一个分片上设置——指示存在 4 字节 TLS Message Length 字段，给出未分片的 TLS 数据总长度。
M (More fragments) Bit 6 Set on all fragments except the last one. The receiver knows reassembly is complete when it receives a fragment without M set. 在除最后一个以外的所有分片上设置。 接收方在收到未设置 M 的分片时知道重组完成。
S (Start) Bit 5 Set only by the server in the initial EAP-Request/EAP-TLS to signal the start of the EAP-TLS conversation. Not related to fragmentation per se. 仅由服务器在初始 EAP-Request/EAP-TLS 中设置， 以信号 EAP-TLS 对话开始。与分片本身无直接关系。
1
Sender fragments TLS data 发送方对 TLS 数据分片

The sender (ISE or supplicant) splits the TLS record into chunks that fit within the EAP MTU. The first chunk has L+M flags set (and includes TLS Message Length). Middle chunks have only M set. The last chunk has neither L nor M set.

发送方（ISE 或请求方）将 TLS 记录拆分为适合 EAP MTU 的块。 第一个块设置 L+M 标志（并包含 TLS 消息长度）。中间块仅设置 M。 最后一个块不设置 L 和 M。

2
Receiver acknowledges each fragment 接收方确认每个分片

For each fragment received (except the last), the receiver sends an empty EAP-Response/EAP-TLS (or EAP-Request/EAP-TLS for server-to-client direction) — a message with Type 13 but zero-length TLS data. This serves as a fragment acknowledgment, triggering the sender to transmit the next fragment.

对于收到的每个分片（最后一个除外），接收方发送一个空的 EAP-Response/EAP-TLS（或服务器到客户端方向的 EAP-Request/EAP-TLS）—— Type 13 但 TLS 数据长度为零的消息。这充当分片确认，触发发送方发送下一个分片。

3
Reassembly and processing 重组与处理

After receiving the final fragment (no M flag), the receiver reassembles the complete TLS record and processes the TLS handshake message(s) within. The receiver then responds with its own TLS data (which may also need fragmentation).

收到最终分片（无 M 标志）后，接收方重组完整的 TLS 记录并处理其中的 TLS 握手消息。 然后接收方回复自己的 TLS 数据（可能也需要分片）。

ℹ Fragmentation Impact on Performance: A typical EAP-TLS handshake with 2048-bit RSA certificates requires 8–12 EAP round trips due to fragmentation. With 4096-bit certificates or long chains, this can exceed 15 round trips. In industrial wireless environments with AGVs, each round trip adds ~2–5 ms latency (Wi-Fi) + ~1–3 ms (RADIUS). Total authentication time can reach 50–150 ms, which matters for time-sensitive AGV roaming. Using ECDSA certificates (smaller keys) and minimizing the certificate chain length significantly reduces fragmentation. ℹ 分片对性能的影响：使用 2048 位 RSA 证书的典型 EAP-TLS 握手由于分片需要 8–12 次 EAP 往返。使用 4096 位证书或较长的证书链时可能超过 15 次往返。在 AGV 工业无线环境中，每次往返 增加约 2–5 ms 延迟（Wi-Fi）+ 约 1–3 ms（RADIUS）。总认证时间可达 50–150 ms，这对时间敏感的 AGV 漫游很重要。使用 ECDSA 证书（更小的密钥） 和最小化证书链长度可显著减少分片。
4

Phase 4 — Authorization & Session Activation 阶段 4 — 授权与会话激活

RFC 3748 §4.2 | IEEE 802.1X-2020 §12.7

With the TLS handshake complete and mutual authentication successful, the EAP method concludes and Cisco ISE makes an authorization decision. This phase transitions the network port from Unauthorized to Authorized state, applying appropriate network access policies to the authenticated AGV.

TLS 握手完成且双向认证成功后，EAP 方法结束，Cisco ISE 做出授权决策。此阶段将网络端口从 未授权状态转换为已授权状态，并对已认证的 AGV 应用相应的网络访问策略。

4a. EAP-Success & RADIUS Access-Accept 4a. EAP-Success 与 RADIUS Access-Accept

←
RADIUS (ISE) → Authenticator RADIUS（ISE）→ 认证者

Cisco ISE sends a RADIUS Access-Accept (Code 2) message to the authenticator. This message contains:

Cisco ISE 向认证者发送 RADIUS Access-Accept（Code 2）消息。此消息包含：

  • EAP-Message attribute (Type 79) containing the EAP-Success packet (Code 3, Identifier matching the last EAP exchange) EAP-Message 属性（Type 79），包含 EAP-Success 数据包（Code 3，Identifier 与最后一次 EAP 交换匹配）
  • MS-MPPE-Send-Key (Type 16) and MS-MPPE-Recv-Key (Type 17) — vendor-specific attributes carrying the MSK (split into two 32-byte halves), encrypted with the RADIUS shared secret MS-MPPE-Send-Key（Type 16）和 MS-MPPE-Recv-Key （Type 17）—— 厂商特定属性，承载 MSK（分为两个 32 字节的半部分）， 用 RADIUS 共享密钥加密
  • Authorization attributes (see §4b below) 授权属性（参见下文 §4b）
  • Message-Authenticator attribute (HMAC-MD5 integrity check, RFC 3579 §3.2) Message-Authenticator 属性（HMAC-MD5 完整性检查，RFC 3579 §3.2）
←
Authenticator → Supplicant 认证者 → 请求方

The authenticator (AP/Switch) extracts the EAP-Success from the RADIUS message and forwards it to the supplicant via EAPOL-EAP (Packet Type 0x00, EtherType 0x888E). The MSK is NOT forwarded to the supplicant — both sides derived it independently from the TLS handshake.

认证者（AP/交换机）从 RADIUS 消息中提取 EAP-Success， 通过 EAPOL-EAP（Packet Type 0x00，EtherType 0x888E）转发至请求方。 MSK 不会转发至请求方——双方从 TLS 握手中独立派生了 MSK。

ℹ TLS 1.3 Protected Success Indication (RFC 9190 §2.5): Before the final EAP-Success, the TLS 1.3 EAP-TLS server sends an application data record containing a single 0x00 byte through the encrypted TLS tunnel. The client MUST receive and validate this byte (it must be exactly 0x00; any other value is a fatal error). The client then responds with an empty EAP-Response, and only then does ISE send the RADIUS Access-Accept with EAP-Success. This mechanism ensures the TLS 1.3 tunnel was properly established and prevents certain truncation attacks. ℹ TLS 1.3 受保护的成功指示（RFC 9190 §2.5）： 在最终 EAP-Success 之前，TLS 1.3 EAP-TLS 服务器通过加密的 TLS 隧道发送包含单个 0x00 字节的应用数据记录。客户端必须接收并验证此字节（必须恰好为 0x00； 任何其他值均为致命错误）。然后客户端回复空的 EAP-Response，之后 ISE 才发送包含 EAP-Success 的 RADIUS Access-Accept。此机制确保 TLS 1.3 隧道正确建立，防止某些截断攻击。

4b. Authorization Attributes 4b. 授权属性

The RADIUS Access-Accept carries authorization attributes that instruct the authenticator how to treat the authenticated session. These are configured in Cisco ISE's Policy → Authorization Policy and matched based on identity, certificate attributes, device type, location, and other conditions.

RADIUS Access-Accept 携带授权属性，指示认证者如何处理已认证的会话。这些属性在 Cisco ISE 的 Policy → Authorization Policy 中配置，根据身份、证书属性、设备类型、位置和其他条件匹配。

Common RADIUS Authorization Attributes for AGV Deployments AGV 部署中常见的 RADIUS 授权属性
Attribute属性 RADIUS TypeRADIUS 类型 Purpose & Example用途与示例
Tunnel-Type Type 64 Value = VLAN (13) — specifies that the tunnel attribute assigns a VLAN 值 = VLAN (13) — 指定隧道属性分配 VLAN
Tunnel-Medium-Type Type 65 Value = 802 (6) — IEEE 802 media type 值 = 802 (6) — IEEE 802 媒体类型
Tunnel-Private-Group-ID Type 81 VLAN name or number (e.g., "AGV_PRODUCTION" or "100"). The AGV is placed into this VLAN upon successful authentication. VLAN 名称或编号（如 "AGV_PRODUCTION" 或 "100"）。 认证成功后 AGV 被放入此 VLAN。
Filter-Id Type 11 References a named ACL on the authenticator (e.g., "AGV-ACL"). The switch/WLC applies this ACL to the port/session. 引用认证者上的命名 ACL（如 "AGV-ACL"）。 交换机/WLC 将此 ACL 应用于端口/会话。
dACL (Downloadable ACL) dACL（可下载 ACL） Cisco VSA (cisco-av-pair) Cisco VSA (cisco-av-pair) ACL content is pushed from ISE to the authenticator via cisco-av-pair = "ip:inacl#..." or via named dACL reference (ACS:CiscoSecure-Defined-ACL). Provides fine-grained per-session access control without pre-configuring ACLs on every switch/AP. Example: permit only AGV fleet management server IPs and deny all other traffic. ACL 内容通过 cisco-av-pair = "ip:inacl#..." 或命名 dACL 引用 （ACS:CiscoSecure-Defined-ACL）从 ISE 推送至认证者。提供细粒度的逐会话访问控制， 无需在每个交换机/AP 上预配置 ACL。示例：仅允许 AGV 车队管理服务器 IP，拒绝所有其他流量。
SGT (Security Group Tag) SGT（安全组标签） Cisco VSA (cisco-av-pair) Cisco VSA (cisco-av-pair) cisco-av-pair = "cts:security-group-tag=0010-00" — Assigns a TrustSec SGT (e.g., tag 16 = "AGV_Devices"). Used for scalable group-based policy enforcement via SGACL (Security Group ACL) across the Cisco SD-Access fabric. More scalable than per-session dACLs in large AGV fleets. cisco-av-pair = "cts:security-group-tag=0010-00" — 分配 TrustSec SGT（如标签 16 = "AGV_Devices"）。用于通过 Cisco SD-Access 架构中的 SGACL（安全组 ACL）实现可扩展的基于组的策略执行。在大型 AGV 车队中比逐会话 dACL 更具可扩展性。
Session-Timeout Type 27 Session duration in seconds before re-authentication is required. Example: 3600 (1 hour). After timeout, the authenticator initiates re-authentication. 需要重新认证前的会话持续时间（秒）。示例：3600（1 小时）。 超时后认证者发起重新认证。
Termination-Action Type 29 Value = RADIUS-Request (1) — upon session timeout, the authenticator performs re-authentication (not disconnection). This allows seamless re-auth without disrupting AGV network connectivity. 值 = RADIUS-Request (1) — 会话超时时， 认证者执行重新认证（而非断开连接）。这允许无缝重新认证而不中断 AGV 网络连接。

4c. Port State Transition → Authorized 4c. 端口状态转换 → 已授权

1
Controlled Port Opens 受控端口打开

The authenticator's PAE (Port Access Entity) transitions the controlled port from Unauthorized to Authorized state (IEEE 802.1X-2020 §6.3.2, §12.3). Data traffic from the AGV can now flow through the controlled port, subject to any applied VLAN assignment, dACL, or SGT policy.

认证者的 PAE（端口访问实体）将受控端口从 未授权 转换为 已授权 状态（IEEE 802.1X-2020 §6.3.2、§12.3）。AGV 的数据流量现在可以通过 受控端口传输，受已应用的 VLAN 分配、dACL 或 SGT 策略约束。

2
802.11 4-Way Handshake (Wireless Only) 802.11 四次握手（仅无线）

For wireless AGV connections via Cisco Catalyst 9800 WLC, the MSK derived from EAP-TLS becomes the PMK (Pairwise Master Key). The AP and supplicant then perform the IEEE 802.11i 4-Way Handshake to derive the PTK (Pairwise Transient Key) and GTK (Group Temporal Key) for wireless frame encryption (AES-CCMP / GCMP).

对于通过 Cisco Catalyst 9800 WLC 的无线 AGV 连接，从 EAP-TLS 派生的 MSK 成为 PMK（成对主密钥）。AP 和请求方随后执行 IEEE 802.11i 四次握手以派生 PTK（成对临时密钥）和 GTK（组临时密钥）， 用于无线帧加密（AES-CCMP / GCMP）。

3
PMKSA Caching (for Fast Roaming) PMKSA 缓存（用于快速漫游）

The PMK and its associated PMKID are cached as a PMKSA (PMK Security Association) at both the supplicant and the authenticator (AP/WLC). On subsequent associations to the same AP or within the same mobility domain, the supplicant can reference the PMKID in the (Re)Association Request to skip the full EAP-TLS handshake, performing only the 4-Way Handshake. See also: 802.11r Fast Transition (FT) and OKC (Opportunistic Key Caching) in the Deployment Notes section.

PMK 及其关联的 PMKID 作为 PMKSA（PMK 安全关联）被缓存在请求方和认证者（AP/WLC）双方。 在后续关联到相同 AP 或同一移动域内时，请求方可在（重新）关联请求中引用 PMKID 以跳过完整的 EAP-TLS 握手，仅执行四次握手。另见部署说明部分的 802.11r 快速转换（FT）和 OKC（机会性密钥缓存）。

4
AGV Network Access Active AGV 网络访问已激活

The AGV now has full network access according to its authorization policy. It can communicate with fleet management servers, receive navigation commands, report telemetry data, and coordinate with other AGVs — all within the security boundaries defined by the VLAN, dACL, and/or SGT policies pushed by Cisco ISE.

AGV 现在根据其授权策略拥有完整的网络访问权限。它可以与车队管理服务器通信、 接收导航命令、报告遥测数据，并与其他 AGV 协调——所有操作均在 Cisco ISE 推送的 VLAN、dACL 和/或 SGT 策略定义的安全边界内。

4d. Session Maintenance & Re-Authentication 4d. 会话维护与重新认证

The authenticated session is not permanent. Several mechanisms manage session lifecycle:

已认证的会话不是永久的。以下几种机制管理会话生命周期：

Session Lifecycle Mechanisms 会话生命周期机制
Mechanism机制 Description描述
Session-Timeout Re-authSession-Timeout 重新认证 When Session-Timeout (Type 27) expires and Termination-Action = RADIUS-Request (1), the authenticator sends a new EAP-Request/Identity to the supplicant, initiating a fresh EAP-TLS handshake transparently (no link disruption). 当 Session-Timeout（Type 27）到期且 Termination-Action = RADIUS-Request (1) 时，认证者向请求方发送新的 EAP-Request/Identity， 透明地发起新的 EAP-TLS 握手（不中断链路）。
RADIUS CoA (Change of Authorization)RADIUS CoA（授权变更） Cisco ISE can send a CoA-Request (RFC 5176) to the authenticator to dynamically change the AGV's authorization (e.g., change VLAN, apply a quarantine ACL) or force re-authentication (CoA-Reauthenticate). Used for posture-based or threat-based policy changes. Cisco ISE 可向认证者发送 CoA-Request（RFC 5176）以动态更改 AGV 的授权（如更改 VLAN、应用隔离 ACL）或强制重新认证 （CoA-Reauthenticate）。用于基于合规性或基于威胁的策略变更。
EAPOL-LogoffEAPOL-Logoff The supplicant sends an EAPOL-Logoff (Packet Type 0x02) when intentionally disconnecting, causing the authenticator to transition the port back to Unauthorized state immediately. 请求方在有意断开连接时发送 EAPOL-Logoff（Packet Type 0x02）， 导致认证者立即将端口转换回未授权状态。
Link Down链路断开 If the physical or wireless link drops, the authenticator immediately transitions the port to Unauthorized and clears the session. The next association triggers a full EAP-TLS authentication (or PMKSA-based fast reconnect if cached). 如果物理或无线链路断开，认证者立即将端口转换为未授权并清除会话。 下一次关联触发完整的 EAP-TLS 认证（如果有缓存则基于 PMKSA 的快速重连）。
ℹ Recommendation for AGV Deployments: Set Session-Timeout ≥ 3600 (1 hour) with Termination-Action = RADIUS-Request. This balances security (periodic certificate re-validation, CRL/OCSP re-check) with operational continuity (AGVs should not experience authentication-related downtime during production shifts). For environments requiring continuous operation, consider 7200 (2 hours) or longer, combined with RADIUS CoA for immediate policy enforcement when needed. ℹ AGV 部署建议：设置 Session-Timeout ≥ 3600 （1 小时），Termination-Action = RADIUS-Request。这在安全性 （定期证书重新验证、CRL/OCSP 重新检查）和运营连续性 （AGV 在生产班次中不应经历认证相关的停机）之间取得平衡。 对于需要持续运行的环境，考虑 7200（2 小时）或更长， 结合 RADIUS CoA 在需要时进行即时策略执行。

📊 Interactive Sequence Diagram — 802.1X EAP-TLS Full Flow 📊 交互式序列图 — 802.1X EAP-TLS 完整流程

The following diagram illustrates the complete 4-phase EAP-TLS mutual authentication sequence between the AGV supplicant, the Catalyst 9800 WLC / Catalyst Switch authenticator, and Cisco ISE RADIUS server. Scroll horizontally on smaller screens. 下图展示了 AGV 申请方、Catalyst 9800 WLC / Catalyst 交换机认证方和 Cisco ISE RADIUS 服务器之间完整的四阶段 EAP-TLS 双向认证序列。在小屏幕上可横向滚动。

802.1X EAP-TLS Sequence Diagram AGV Supplicant AGV 申请方 802.1X Client AP / Switch AP / 交换机 Authenticator 认证方 Cisco ISE RADIUS Server AGV Supplicant AGV 申请方 802.1X Client AP / Switch AP / 交换机 Authenticator 认证方 Cisco ISE RADIUS Server PHASE 1 — 802.11 Association & EAPOL Start 阶段 1 — 802.11 关联 & EAPOL 启动 802.11 Probe Req / Auth / Assoc Req 802.11 探测/认证/关联请求 802.11 Probe Resp / Auth / Assoc Resp 802.11 探测/认证/关联响应 Controlled port BLOCKED 受控端口被阻塞 EAPOL-Start EtherType 0x888E 以太类型 0x888E EAP-Request/Identity EAP-Response/Identity ID = AGV certificate CN/SAN ID = AGV 证书 CN/SAN PHASE 2 — EAP Identity Relay & Method Selection 阶段 2 — EAP 身份中继 & 方法选择 RADIUS Access-Request EAP-Message = EAP-Response/Identity EAP-Message = EAP-Response/Identity RADIUS Access-Challenge EAP-Request/EAP-TLS (Start, S=1) EAP-Request/EAP-TLS（启动，S=1） EAP-Request/EAP-TLS (Start) Type=13, Flags: S=1 类型=13，标志：S=1 EAP-TLS method selected EAP-TLS 方法已选定 PHASE 3 — TLS 1.2 Mutual Authentication Handshake 阶段 3 — TLS 1.2 双向认证握手 EAP-Response / TLS ClientHello RADIUS Access-Request EAP-Message = ClientHello EAP-Message = ClientHello RADIUS Access-Challenge EAP-Request / TLS Server Flight ServerHello + Certificate + CertificateRequest + ServerHelloDone ServerHello + 证书 + 证书请求 + ServerHelloDone ⟵ May be fragmented (L,M flags) ⟵ 可能分片（L,M 标志） Validate 验证 Server Cert 服务器证书 Chain → Root CA trust 证书链 → 根 CA 信任 Signature, Validity, CRL/OCSP 签名、有效期、CRL/OCSP EAP-Response / TLS Client Flight Certificate + ClientKeyExchange + CertificateVerify + CCS + Finished 证书 + 客户端密钥交换 + 证书验证 + CCS + Finished RADIUS Access-Request EAP-Message = Client Flight (fragmented) EAP-Message = 客户端飞行数据（分片） Validate 验证 Client Cert 客户端证书 Chain validation, CN/SAN 链验证、CN/SAN Validity, CRL/OCSP check 有效期、CRL/OCSP 检查 CertificateVerify signature ✓ CertificateVerify 签名 ✓ RADIUS Access-Challenge EAP-Request/EAP-TLS (CCS + Finished) EAP-Request/EAP-TLS（CCS + Finished） EAP-Request / TLS CCS + Finished 🔒 TLS Tunnel Established 🔒 TLS 隧道已建立 EAP-Response / EAP-TLS (empty) TLS handshake complete ACK TLS 握手完成确认 RADIUS Access-Request EAP-Message = empty TLS data EAP-Message = 空 TLS 数据 Key Derivation: TLS master_secret → PRF → 密钥推导：TLS master_secret → PRF → MSK (64B) + EMSK (64B) [RFC 5216 §2.3] MSK（64B）+ EMSK（64B）[RFC 5216 §2.3] PHASE 4 — Authorization & Port Enablement 阶段 4 — 授权 & 端口启用 RADIUS Access-Accept EAP-Success + MS-MPPE-Keys + AuthZ attrs EAP-Success + MS-MPPE-Keys + 授权属性 EAP-Success AuthZ: VLAN, dACL, SGT 授权：VLAN、dACL、SGT Session-Timeout, Termination-Action Session-Timeout、Termination-Action Filter-Id / Airespace-ACL-Name Filter-Id / Airespace-ACL-Name ✅ Controlled Port OPEN ✅ 受控端口已开放 802.11i 4-Way Handshake (Msg 1) 802.11i 四次握手（消息 1） 4-Way Handshake (Msg 2) 四次握手（消息 2） 4-Way Handshake (Msg 3) 四次握手（消息 3） 4-Way Handshake (Msg 4) 四次握手（消息 4） PMKSA cached for fast roaming PMKSA 已缓存用于快速漫游 🚗 AGV Full Network Access Active 🚗 AGV 完全网络接入已激活

🏭 Deployment Notes — Industrial AGV with Cisco ISE 🏭 部署注意事项 — 工业 AGV 与 Cisco ISE

The following operational guidelines address certificate lifecycle, roaming performance, session management, cipher selection, revocation checking, and RADIUS infrastructure design for AGV 802.1X EAP-TLS deployments. 以下运营指南涵盖 AGV 802.1X EAP-TLS 部署中的证书生命周期、漫游性能、会话管理、密码套件选择、吊销检查和 RADIUS 基础设施设计。

📜 Certificate Management证书管理

  • Use SCEP (Simple Certificate Enrollment Protocol) or EST (Enrollment over Secure Transport, RFC 7030) for automated AGV certificate enrollment and renewal. 使用 SCEP（简单证书注册协议）或 EST（安全传输注册，RFC 7030）实现 AGV 证书的自动注册和续期。
  • Ensure the CA trust chain is consistent across all AGVs, ISE nodes, and authenticators. Import intermediate CA certificates into the ISE Trusted Certificates store. 确保所有 AGV、ISE 节点和认证方之间的 CA 信任链 一致。将中间 CA 证书导入 ISE 受信任证书库。
  • Set certificate validity to 1–2 years for device certificates; automate renewal 30 days before expiry to prevent authentication failures during AGV operation. 设备证书有效期设为 1–2 年；在到期前 30 天自动续期，防止 AGV 运行期间认证失败。
  • Use SAN (Subject Alternative Name) fields (dNSName or iPAddress) for machine identity; avoid relying solely on CN for certificate matching in ISE policies. 使用 SAN（主题备用名称） 字段（dNSName 或 iPAddress）标识设备身份；避免在 ISE 策略中仅依赖 CN 进行证书匹配。
  • Store private keys in a TPM (Trusted Platform Module) or hardware secure element on the AGV where possible to prevent key extraction. 尽可能将私钥存储在 AGV 的 TPM（可信平台模块）或硬件安全元件中，以防止密钥被提取。

⚡ Low-Latency Requirements & Roaming低延迟要求和漫游

  • Enable PMKSA Caching on the Catalyst 9800 WLC to allow AGVs to skip full EAP-TLS re-authentication when roaming between APs within the same mobility domain. 在 Catalyst 9800 WLC 上启用 PMKSA 缓存，使 AGV 在同一移动域内的 AP 之间漫游时跳过完整的 EAP-TLS 重新认证。
  • Configure OKC (Opportunistic Key Caching) as a fallback for PMKSA distribution across WLC-managed APs. 配置 OKC（机会性密钥缓存） 作为 WLC 管理的 AP 之间 PMKSA 分发的备用方案。
  • Deploy 802.11r (Fast BSS Transition) for sub-50ms roaming. Ensure over-the-DS mode is used in dense industrial RF environments for reliability. 部署 802.11r（快速 BSS 转换） 实现低于 50ms 的漫游。在密集的工业 RF 环境中使用 over-the-DS 模式以提高可靠性。
  • Full EAP-TLS handshake typically takes 6–12 round trips (100–500ms on WLAN). Target roaming scenarios should use PMKSA/OKC/FT to avoid this latency. 完整的 EAP-TLS 握手通常需要 6–12 次往返（WLAN 上 100–500ms）。漫游场景应使用 PMKSA/OKC/FT 来避免此延迟。
  • Consider pre-authentication (802.11i) to neighboring APs when AGV travel paths are predictable in warehouse/factory floor layouts. 当 AGV 在仓库/工厂车间的行驶路径可预测时，考虑对邻近 AP 进行 预认证（802.11i）。

🔄 Re-authentication & Session Management重新认证和会话管理

  • Set Session-Timeout ≥ 3600 seconds in the ISE Authorization Profile to minimize re-authentication frequency for continuously operating AGVs. 在 ISE 授权配置文件中设置 Session-Timeout ≥ 3600 秒，以减少持续运行的 AGV 的重新认证频率。
  • Set Termination-Action = RADIUS-Request (1) to ensure re-authentication occurs via a new RADIUS exchange rather than session teardown. 设置 Termination-Action = RADIUS-Request (1)，确保通过新的 RADIUS 交换进行重新认证而非终止会话。
  • Leverage RADIUS CoA (Change of Authorization) for dynamic policy updates (e.g., moving an AGV to quarantine VLAN upon security alert) without requiring re-authentication. 利用 RADIUS CoA（授权变更） 实现动态策略更新（例如在安全警报时将 AGV 移至隔离 VLAN），无需重新认证。
  • Monitor EAPOL-Logoff frames; AGVs powering down should trigger session cleanup on the authenticator and ISE. 监控 EAPOL-Logoff 帧；AGV 关机时应触发认证方和 ISE 上的会话清理。

🔐 Cipher Suite Selection密码套件选择

  • TLS 1.2 Preferred: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 or TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for optimal balance of security and performance on embedded AGV hardware. TLS 1.2 首选：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 或 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256，在嵌入式 AGV 硬件上实现安全性和性能的最佳平衡。
  • TLS 1.3 Preferred: TLS_AES_256_GCM_SHA384 for maximum security; TLS_AES_128_GCM_SHA256 for resource-constrained AGV controllers. TLS 1.3 首选：TLS_AES_256_GCM_SHA384 提供最大安全性；TLS_AES_128_GCM_SHA256 适用于资源受限的 AGV 控制器。
  • Disable legacy cipher suites: CBC-mode ciphers, RC4, 3DES, SHA-1-based MACs, and static RSA key exchange must be disabled on both ISE and supplicant. 禁用旧版密码套件：必须在 ISE 和申请方上禁用 CBC 模式密码、RC4、3DES、基于 SHA-1 的 MAC 和静态 RSA 密钥交换。
  • For AGVs with hardware crypto acceleration (AES-NI equivalent), prefer AES-256-GCM. For software-only TLS stacks, AES-128-GCM offers lower CPU overhead. 对于具有 硬件加密加速（AES-NI 等效）的 AGV，优先使用 AES-256-GCM。对于仅软件 TLS 栈，AES-128-GCM 提供更低的 CPU 开销。

📋 CRL / OCSP Revocation CheckingCRL / OCSP 吊销检查

  • Configure ISE to check OCSP (Online Certificate Status Protocol) as the primary revocation method for real-time status. Set CRL as fallback. 配置 ISE 使用 OCSP（在线证书状态协议） 作为主要吊销检查方法以获取实时状态。将 CRL 设为备用。
  • Set CRL download interval appropriately (e.g., every 4–8 hours) to balance freshness against ISE resource usage. Cache CRL in ISE local store. 适当设置 CRL 下载间隔（例如每 4–8 小时），以平衡新鲜度和 ISE 资源使用。在 ISE 本地存储中缓存 CRL。
  • Enable OCSP Nonce to prevent replay attacks if the OCSP responder supports it. If not, use short-lived OCSP response caching (≤ 5 min). 如果 OCSP 响应程序支持，启用 OCSP Nonce 以防止重放攻击。否则，使用短期 OCSP 响应缓存（≤ 5 分钟）。
  • In ISE → Administration → Certificates → Certificate Store, configure the OCSP responder URL and CRL Distribution Point (CDP) for each trusted CA. 在 ISE → 管理 → 证书 → 证书库 中，为每个受信任的 CA 配置 OCSP 响应程序 URL 和 CRL 分发点（CDP）。
  • Decide ISE behavior when revocation check is unreachable: "Allow" (less secure, more available) vs. "Reject" (more secure, risk of false negatives). For safety-critical AGV operations, consider "Reject" with RADIUS redundancy. 决定吊销检查不可达时的 ISE 行为："允许"（安全性较低，可用性更高）vs. "拒绝"（安全性更高，存在误判风险）。对于安全关键的 AGV 操作，建议配合 RADIUS 冗余使用"拒绝"。

🌐 RADIUS Redundancy & InfrastructureRADIUS 冗余与基础设施

  • Deploy at least two ISE PSN (Policy Service Nodes) — primary and secondary — for RADIUS high availability. Configure on the WLC / switch using radius server groups with failover. 部署至少 两个 ISE PSN（策略服务节点） — 主节点和备用节点 — 以实现 RADIUS 高可用性。在 WLC / 交换机上使用 radius server 组配置故障转移。
  • Use RADIUS load balancing on the Catalyst 9800 WLC (radius-server load-balance method least-outstanding) to distribute authentication requests across PSNs. 在 Catalyst 9800 WLC 上使用 RADIUS 负载均衡（radius-server load-balance method least-outstanding）将认证请求分配到各 PSN。
  • Set RADIUS dead-server detection with appropriate timeout (e.g., radius-server dead-criteria time 5 tries 3) to quickly failover without impacting AGV connectivity. 设置 RADIUS 死服务器检测（例如 radius-server dead-criteria time 5 tries 3），以便快速故障转移而不影响 AGV 连接。
  • Ensure RADIUS shared secrets are strong (≥ 22 characters, mixed case + symbols) and unique per authenticator/ISE pair. Use RADIUS/DTLS (RFC 7360) where supported for transport encryption. 确保 RADIUS 共享密钥 强度足够（≥ 22 个字符，大小写混合 + 符号）且每对认证方/ISE 唯一。在支持的设备上使用 RADIUS/DTLS（RFC 7360）进行传输加密。
  • Place ISE PSN nodes local to the factory/warehouse site to minimize RADIUS round-trip latency. Avoid WAN-dependent RADIUS paths for real-time AGV authentication. 将 ISE PSN 节点部署在 工厂/仓库站点本地，以最小化 RADIUS 往返延迟。避免实时 AGV 认证依赖 WAN 的 RADIUS 路径。

📖 Glossary 📖 术语表

802.1X
IEEE standard for port-based Network Access Control (PNAC). Defines three roles: supplicant, authenticator, and authentication server. Current revision: IEEE 802.1X-2020. IEEE 基于端口的网络访问控制 (PNAC) 标准。定义三个角色：申请方、认证方和认证服务器。当前版本：IEEE 802.1X-2020。
EAP
Extensible Authentication Protocol (RFC 3748). A flexible framework that transports authentication methods between supplicant and authentication server via the authenticator. 可扩展认证协议（RFC 3748）。一种灵活框架，通过认证方在申请方和认证服务器之间传输认证方法。
EAP-TLS
EAP Transport Layer Security (RFC 5216 for TLS 1.2, RFC 9190 for TLS 1.3). Provides mutual certificate-based authentication — both client and server present X.509 certificates. Considered the gold standard for EAP security. EAP 传输层安全（TLS 1.2 为 RFC 5216，TLS 1.3 为 RFC 9190）。提供基于证书的双向认证——客户端和服务器均出示 X.509 证书。被认为是 EAP 安全性的最高标准。
EAPOL
EAP over LAN (IEEE 802.1X). Layer 2 encapsulation protocol for carrying EAP frames between supplicant and authenticator using EtherType 0x888E. Includes Start, Logoff, Key, and Packet frame types. 局域网上的 EAP（IEEE 802.1X）。第 2 层封装协议，使用以太类型 0x888E 在申请方和认证方之间传输 EAP 帧。包括 Start、Logoff、Key 和 Packet 帧类型。
Supplicant 申请方 (Supplicant)
The entity (AGV, endpoint device) seeking network access. Runs 802.1X client software that initiates EAPOL exchanges and provides credentials (certificates in EAP-TLS). 寻求网络访问的实体（AGV、终端设备）。运行 802.1X 客户端软件，发起 EAPOL 交换并提供凭据（EAP-TLS 中为证书）。
Authenticator 认证方 (Authenticator)
The network access device (Catalyst 9800 WLC AP or Catalyst Switch) that enforces access control. Relays EAP messages between supplicant and authentication server; controls the port state (blocked/authorized). 执行访问控制的网络接入设备（Catalyst 9800 WLC AP 或 Catalyst 交换机）。在申请方和认证服务器之间中继 EAP 消息；控制端口状态（阻塞/授权）。
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Client-server protocol used between the authenticator and ISE for AAA (Authentication, Authorization, Accounting). Carries EAP messages in RADIUS attributes. 远程认证拨入用户服务（RFC 2865）。认证方与 ISE 之间用于 AAA（认证、授权、计费）的客户端-服务器协议。在 RADIUS 属性中承载 EAP 消息。
ISE
Cisco Identity Services Engine. A centralized policy platform providing AAA, posture assessment, profiling, guest access, and BYOD management. Serves as the RADIUS/EAP authentication server in 802.1X deployments. Cisco 身份服务引擎。提供 AAA、合规评估、设备分析、访客访问和 BYOD 管理的集中策略平台。在 802.1X 部署中充当 RADIUS/EAP 认证服务器。
dACL
Downloadable Access Control List. An ACL pushed from ISE to the authenticator via RADIUS during authorization. Provides per-session, per-user/device granular traffic filtering. Referenced by the Filter-Id or cisco-av-pair RADIUS attribute. 可下载访问控制列表。在授权期间通过 RADIUS 从 ISE 推送到认证方的 ACL。提供按会话、按用户/设备的精细流量过滤。通过 Filter-Id 或 cisco-av-pair RADIUS 属性引用。
SGT
Scalable Group Tag (Cisco TrustSec). A 16-bit security label assigned during authorization that enables software-defined segmentation. SGT-based policies (SGACLs) enforce access between groups without traditional ACLs. 可扩展组标签（Cisco TrustSec）。在授权期间分配的 16 位安全标签，实现软件定义的网络分段。基于 SGT 的策略（SGACL）无需传统 ACL 即可在组之间实施访问控制。
PMKSA
Pairwise Master Key Security Association. Cached result of a successful 802.1X/EAP authentication in wireless networks. Allows fast reconnection and roaming by skipping full EAP re-authentication. Identified by PMKID. 成对主密钥安全关联。无线网络中成功 802.1X/EAP 认证的缓存结果。通过跳过完整的 EAP 重新认证实现快速重连和漫游。由 PMKID 标识。
802.11r (FT)
IEEE 802.11r — Fast BSS Transition. An amendment to 802.11 that enables fast, secure handoffs between APs by pre-distributing PMK-R1 keys. Targets < 50 ms roaming for latency-sensitive applications like AGV navigation. IEEE 802.11r — 快速 BSS 转换。802.11 的修订版，通过预分发 PMK-R1 密钥实现 AP 之间的快速安全切换。目标漫游时间 < 50ms，适用于 AGV 导航等延迟敏感应用。