摘要

  • RFC 9965 为请求特定配置路径和有限未认证连接的 Network Access Identifier 保留了 eap.arpa。
  • 请求、EAP 方法选择、服务器认证、受限网络执行、凭据签发和普通准入，是彼此独立的记录与决定。

一台陌生设备提交了以 eap.arpa 结尾的标识符。网络可以把它读作“我需要取得凭据的帮助”的请求，不能把它读成凭据本身。这正是 RFC 9965《The eap.arpa. Domain and Extensible Authentication Protocol Provisioning》的关键克制。

该 RFC 定义 EAP Provisioning Identifier（EPI）：其 realm 是 eap.arpa. 子域的 NAI。该 realm 有意不绑定某个组织。标准不要求把它自动代理给既有 AAA 系统，也不要求以通常的动态对等方发现来解析；但它没有禁止本地组织自行决定如何路由。因此，共享语法只说明对等端如何请求配置方法，接收方仍须决定是否受理、交给哪里、以哪些证据处理。

这也说明 realm 字符串为何只是弱证据。它至多证明对等端在 EAP 身份交换中发出了某种请求，不能证明谁拥有该设备、哪个组织负责、哪个后端处理了请求，或某个认证方法已完成。把 @method.eap.arpa 日志直接写成“可信设备”，等于用一个可观察消息替换了多项未被观察的决定。

RFC 9965 对这些决定之前的状态说得很清楚：采用 EPI 的对等端必须被视为不可信。一旦接受某种配置方法，对等端只能进入有限网络，例如 captive portal；该网络不得允许无限制访问。安全的配置网络应只允许预期流量、阻断其他流量。只封禁若干“坏”目的地的设计留下了更大、也更难审计的暴露面。

方法边界同样不能跳过。EPI 选择的是所请求的配置方法；如果 EAP 服务器接受该请求，提供的方法必须与 EPI 关联的方法一致，然后才继续通常的 EAP 状态机。RFC 3748 将 EAP 定义为承载多种方法的认证框架，并明确指出：认证过的对等端仍可能因策略、会话限制或其他原因被拒绝访问。因此，方法选择既不是 EAP 成功，也不是一般性授权。

服务器认证是另一层。RFC 9965 要求 eap.arpa. 下的每一种配置方法说明如何认证服务器，并建议在能提供服务器认证、完整性和保密性的场合使用基于 TLS 的 EAP。这是方法设计的要求，而不是某一会话已经验证某张证书的证明。真正可用的审计链应分别保留：EPI 请求、本地路由决定、所选方法、服务器认证证据、实际执行的受限网络规则、凭据决定，以及之后的访问决定；任何一项都不应自动继承上一项的权威性。