摘要

  • RFC 5421 记录了 EAP-FAST-GTC 如何在隧道内使用已分配给 EAP-GTC 的 Type 6，却承载不同格式的内部方法交换。
  • “隧道内外不得互换”的规定和 IESG 的兼容性警告，说明 EAP-FAST 上下文参与了方法身份判定；这是对实现的推论，并非已测得的故障证据。

一个字节，不是完整身份

EAP 的 Type 字段只有一个字节，却决定了后续处理路径。RFC 3748 说明它标识方法，EAP 层会根据 Type 把报文分派给相应方法；RFC 将这种作用比作传输层端口。看到 Type 6，直觉上的答案就是 Generic Token Card。

RFC 5421 增加了一个不能从这个字节单独读出的上下文。2009 年发布的 Informational 备忘录描述了 EAP-FAST-GTC：一种用于基本密码交换的内部方法，可服务于遗留密码数据库、密码变更和一次性密码流程。出于历史原因，它沿用了原先分配给 EAP-GTC 的代码。IANA 当前注册表仍把 Type 6 列为“Generic Token Card”；RFC 5421 没有新增一个全局类型分配。

区别在封装和载荷。EAP-FAST 先建立 TLS 隧道；在其内部阶段，EAP 报文被放入 EAP Payload TLV。RFC 5421 指出，EAP-FAST-GTC 有特定的载荷格式，不一定兼容隧道外的 EAP-GTC 机制。因此，它规定两个对称边界：EAP-FAST-GTC MUST NOT 在 EAP-FAST 隧道外使用，EAP-GTC MUST NOT 在隧道内使用。

这两条规则也定义了不同场景里的 Type 6 含义。若分派器只保留 Type 字节，却丢掉报文来自外层交换还是 EAP-FAST 内部阶段的信息，它就丢失了协议用来区分两种方法的上下文。这里说的是规范带来的实现含义，并不是声称现实系统已经犯过这种错误。

兼容性警告写在标准文本里

RFC 5421 随附的 IESG Note 明确称，复用已分配的 EAP Type Code 与 RFC 3748 定义的方法协商不兼容。EAP-GTC 没有方法专属的版本协商，所以报文在 EAP-FAST 隧道内时，才会默认其含义是 EAP-FAST-GTC。说明还指出，当实现同时需要兼容另一家厂商的 EAP-GTC 时，复用可能造成问题；同一方法码在隧道内外承担不同含义，也会迫使实现增加特殊分派逻辑。若今天重新设计 EAP-FAST，使用独立 Type Code 可以避开这些困难。该说明要求未来隧道方法不得给已分配的方法类型赋予不同含义。

这段话的范围必须说准：RFC 没有证明每次协商都会失败，没有撤销 Type 6，也没有认定某款当前产品存在缺陷。它记录的是因上下文相关含义而产生的兼容成本。注册表保留全局名称，隧道规则限定内部用途，IESG Note 则解释二者之间的张力。

“运行中的代码优先”可以作为理解这一问题的编辑视角：注册表条目并不是完整系统。真正的处理还要看收到报文的代码如何判断层次并选择方法。Heng Lu 的 Note 65 只提供这种观察角度，不是 EAP 规范要求、厂商行为或部署情况的证据。

凭据保护是另一条边界

RFC 5421 还说明，EAP-FAST-GTC 会发送明文密码字符串，但这些字符串位于加密的 TLS 隧道内。对端必须先认证服务器，才能披露凭据；由于 Server-Unauthenticated Provisioning Mode 不会认证服务器，EAP-FAST-GTC MUST NOT 在该模式中充当内部方法。这是一项重要的安全条件，却与 Type Code 的选择问题不同：保护凭据不自动解决方法分派，正确识别方法也不自动证明服务器已认证。

运营审查应定位到边界：系统在哪里决定 Type 6 表示普通 EAP-GTC，还是隧道内的 EAP-FAST-GTC？判断应同时利用 Type 和 EAP-FAST 阶段，并执行内外互斥规则。测试可以分别确认隧道外允许普通 GTC、隧道内使用 FAST-GTC，并验证反向组合会被拒绝。本文提出的是验证做法，不是额外增加 RFC 要求。

RFC 5421 的状态是 Informational。现有公开来源不能证明当下的采用率、厂商实现或实际事故。它更有限也更有用的提醒是：当方法码在隧道内被复用时，承载它的外层框架就成为分派器不能随手丢弃的运行时上下文。

来源