摘要

  • RFC 5281 把 EAP-TTLSv0 分为 TLS 握手与受保护的数据阶段。未使用客户端证书时，第一阶段只让客户端认证 TTLS 服务器，真实用户身份要到第二阶段才进入系统。
  • 完整接入收据应连接外层路由身份、服务器证书、内层方法与身份、AAA 结论、授权版本、密钥交付、接入点执行和真实流量；任何早期成功都不能替后续边界作证。

Finished 只表示下一步可以安全开始

第一阶段以 TLS 建立保护。TTLS 服务器出示证书，客户端依据受信 CA、预期名称和策略验证它；客户端是否也用证书证明自己是可选项。双方交换 ChangeCipherSpec 与 Finished 后，记录层能够保护后续内容。

这个时点的主语是“服务器与通道”。在单向 TLS 分支中，订阅者还没有完成认证。第二阶段才把用户名、密码证明、内部 EAP、完整性或配置信息封装为 AVP，通过隧道提交。

因此，TLS 成功不是用户成功。它也不是 AAA 接受、授权下发、接入点执行、链路加密或应用可用。RFC 5281 的两阶段结构就是为了让这些事实按顺序发生。

该文档属于 Informational，并记录当时已有实现。RFC 8996 后来禁止 TLS 1.0 和 1.1，RFC 9427 为 TLS 1.3 更新了 EAP-TTLS 的密钥派生与结果处理。现代实现必须采用后来的规则，但身份边界并未因算法升级而消失。

外层身份首先是一张路由标签

隧道建立前，接入点通常会索要 EAP-Response/Identity。它以明文出现。RFC 5281 为保护用户隐私，建议不要写真实用户名，可以发送空值或匿名占位符，只保留把请求路由到可信提供者所需的 realm。

匿名加域名能回答“这次认证应送往哪里”，不能回答“谁正在申请访问”。真实用户身份随后在加密通道内出现，交给本地域 AAA 权威判断。

如果日志只有一个 identity 字段，系统往往会覆盖其中之一。用内层用户名覆盖外层值，会丢失路由路径；只保留外层匿名值，又会把 AAA 决定错误归给占位符。两者必须分别存储，并注明观察者、时间和用途。

隧道在 TTLS 终端结束

内层 AVP 只在客户端到 TTLS 服务器之间受这条 TLS 隧道保护。服务器终止 TLS，把 AVP 恢复为明文，再经 RADIUS、Diameter 或其他 AAA 承载协议转给 AAA/H。

TTLS 与 AAA/H 可以是同一逻辑设备，也可以分离，中间还可能有代理。因此，外层 TLS 不是从客户端一直延伸到最终身份权威的端到端加密。后端承载有自己的身份、完整性、保密性和路由风险。

TTLS 终端也不是透明管道。它能看见凭证并转换属性。RFC 5281 特别提醒，相同 AVP 代码在不同上下文中不一定有相同语义；只有理解两端定义时才能复制。语法兼容不是语义授权。

用户认证可能是一串政策判断

AAA/H 可以挑战、接受或拒绝。挑战通过 TTLS 服务器回到加密通道，客户端继续回应，直至权威作出结论。外层 EAP 随后通常得到 EAP-Success 或 EAP-Failure。

内层还可以连续运行多种认证方法，例如密码之后再验证令牌。总体成功究竟要求全部通过还是至少一个通过，由策略决定。单个“方法成功”计数不能代表整条政策结论。

有时第二阶段可以合法省略：第一阶段的客户端证书已经完成所需认证，或恢复的会话继承了一次先前成功。监控必须识别分支，而不能把“无 phase 2”一概判为错误。

反向错误更危险：把仅完成 TLS、但用户认证失败的会话放入可恢复缓存。RFC 5281 称其后果为灾难性，因为攻击者可恢复那个会话并绕过失败的内层检查。缓存资格必须来自成功的用户认证，而不是来自握手本身。

能派生密钥不等于获准使用网络

TLS 秘密与随机值可以派生 MSK 和 EMSK。成功认证结束时，TTLS 服务器通过 AAA 承载向接入点交付密钥材料与授权信息。

数学上能够产生字节，与政策上允许使用字节并非同一事实。候选密钥可能在拒绝之前已经可计算，可能关联错误会话，可能伴随过期策略，也可能抵达一个未正确安装它的接入点。

收据需要把密钥标识连接到 TLS transcript、用户身份、AAA 决定、接入会话和安装状态。否则“生成了密钥”只是密码学能力，不是访问结果。

成功沿两条路径离开权威

客户端通常看到 EAP-Success。接入点则经 AAA 路径获得 Access-Accept、密钥以及过滤、时限、逻辑网络或带宽等授权参数。两条路径源于同一判断，却由不同参与者接收。

客户端的成功报文不能证明接入点执行了策略。接入点收到接受也不能证明客户端看到了结果。即使链路保护激活，地址、路由、DNS 和应用仍可能失败。

因此，声称“访问恢复”还需要执行点的状态回读、双向数据以及相关应用结果。身份权威能证明它的决定，不能借由一个 success 字段观察所有后果。

基础版本缺少外内层绑定

RFC 5281 明确指出 EAP-TTLSv0 没有把外层 TLS 认证与内层认证进行密码学绑定。若同一凭证证明既能用于隧道内，也能用于不受保护的外部方法，攻击者可能在两个上下文之间转发证明。

文档建议避免这种凭证复用，并采用绑定扩展。两个步骤分别成功，不自动等于它们属于同一端点和同一会话。也不能把后来方法的属性倒填给基础版本；必须记录实际使用的版本与绑定机制。

一份按权限转移排列的接入收据

高后果系统至少应保存：

  • 客户端、接入点、TTLS 终端与 AAA/H 身份；
  • 外层匿名身份、realm 和代理路由；
  • 服务器证书链、预期名称与验证策略；
  • TLS 版本、密码套件、transcript 与第一阶段结束；
  • 客户端证书分支、内层分支或会话恢复依据；
  • 内层用户身份、方法序列、挑战与结果；
  • TTLS 到 AAA/H 的交易与承载保护；
  • AAA 决定、策略代次和授权参数；
  • 客户端观察到的 EAP 结果；
  • MSK 交付及其与正确接入会话的绑定；
  • 实际安装的过滤、网络、时限和带宽限制；
  • 链路保护状态与第一批双向流量；
  • 报告所声称的应用结果。

这样，任何一层失败都不会篡改前一层的事实。隧道正确可以与用户被拒绝并存；用户获准可以与执行失败并存；策略已执行也可以与业务不可用并存。明确边界，才能阻止第一盏绿灯接管整条证据链。

Sources