摘要

  • RFC 927 提出 Telnet 选项 26 TUID：已经认证用户的主机可向同意接收的目标发送一个 32 比特二进制用户编号，从而免去第二次登录。
  • 发送编号前必须先完成 WILL TUID 与 DO TUID 的合意；WON'T 与 DON'T 让任一端的拒绝都成为正常协议结果。
  • 四个八位组只标识源主机所声称的用户，不能独自证明密码检查、授予目标主机权限、提供密码学保护，或证明应用动作已经发生。

1984 年 12 月，BBN 的 Brian A. Anderson 发布 RFC 927，题为 TACACS User Identification Telnet Option。它处理的不是抽象身份哲学，而是登录过程中的一次真实重复：用户已经向 Terminal Access Controller（TAC）提交正确的姓名与密码，TAC 代表用户连接目标主机时，目标又可能要求再输一次。

提案把解决办法命名为 TUID，分配 Telnet 选项代码 26。用户侧 Telnet 可以表示自己将认证用户并发送 UUID；服务器侧 Telnet 可以表示愿意接受对方所做的认证。双方同意后，一个 32 比特二进制数才会进入子协商。

密码没有被缩成四个八位组。跨过连接的是一项声明：源主机说自己已经完成认证，并以这个数字标识用户。目标主机仍要决定，这句话是否足以打开自己的入口。

被省掉的提示框变成了主机间信任

RFC 927 对动机的描述很清楚。TACACS 要求用户先向 TAC 给出正确的姓名/密码组合，然后才能通过 TAC 连接其他主机。若想避免目标主机再做一次认证，TAC 可以把文本所谓用户的“proven identity”——其 UUID——传给目标。

这里的“已证明”属于源系统的认证过程，并不附着在四个八位组上。目标看不到原密码交换，无法仅凭编号重做检查。它只能判断源主机的认证制度、账号管理和本次声明是否值得依赖。

规范随后给出关键限制：主机可以接受 TAC 的认证，也可以不接受，由自己选择。源主机有权陈述自己做过什么；它无权替目标主机决定谁能使用目标的服务。减少一次人机交互，增加的是一条有边界的信任依赖。

先同意交接，再发送编号

RFC 854 把 Telnet 设计为最小 Network Virtual Terminal 加可协商选项。WILL、DO、WON'T、DON'T 让双方提出、接受或拒绝额外行为。RFC 855 又规定，带参数的选项必须分两步：先确认两端都同意使用该选项，再通过子协商传参数。

TUID 用这套语法分配责任：

  • IAC WILL TUID 表示用户侧愿意认证所代表的用户并发送其 UUID；
  • IAC DO TUID 表示服务器侧希望收到该值，并同意接受对方对这个用户的认证；
  • IAC WON'T TUID 表示源端拒绝承担认证与发送；
  • IAC DON'T TUID 表示目标端拒绝接受这份认证。

只有 WILL 与 DO 对齐后，IAC SB TUID <uuid> IAC SE 才发送四个八位组。RFC 927 展示了两种成功顺序：服务器先要求，或用户侧先提议；也展示了两种明确失败：一端用 WON'T，另一端用 DON'T。

默认值同样重要。不实现 TUID 的用户端对 DO 回答 WON'T；不实现它的服务器端对 WILL 回答 DON'T。不了解选项不会被解释成默许信任，连接仍可退回普通 Telnet，由目标执行自己的登录规则。

这里的 UUID 只有 32 比特

今天看到 UUID，人们往往想到带连字符的 128 比特格式。RFC 927 明确定义的是“32 bit binary number”。它给出的示例把数值 1、255 和全一值直接放进 Telnet 子协商，没有现代 UUID 的文本形式。

Telnet 把八位组 255 保留为 IAC。因此，如果用户编号中出现 255，就要把这个八位组重复一次。数值 255 会表示为三个零八位组加 IAC IAC；全一值要连续出现四组重复的 IAC。这叫数据透明，不是加密、签名或完整性认证。

RFC 927 没有规定编号由谁全球分配，如何避免碰撞，多久失效，是否可重用，也没有 nonce、时间戳、MAC、签名或信道绑定。它同样没有规定目标怎样把编号映射为本地账号。一个格式正确的四字节值，只能在已知源主机、已知编号空间和已知信任政策中获得意义。

因此，抓包看到合法的 TUID 子协商，可以证明某端在选项启用后把四个八位组当作用户编号提交。它不能证明哪一个人输入了密码、源端是否正确执行政策、编号是否刚被重新分配，或目标是否选中了正确账号。

接受认证，不等于授予行动权限

目标接受上游认证，只回答一个有限问题：它是否把源主机的陈述当作足够的身份依据。RFC 927 没有因此授予文件读取、命令执行、特权模式或应用操作权限。

较晚的 RFC 1492 可以帮助看清区别，但不能倒写 1984 年。它在 1993 年以 Informational 文档重构 TACACS，描述终端接入设备把姓名和密码送给 daemon，由主机决定接受或拒绝；它还把 CONNECT 写成已存在登录上下文中的另一项请求，用来询问能否连接某个地址与端口。识别用户与准许目的地是两次决定。

这份后期资料本身带有不确定性。作者因版权问题无法取得原始 TACACS 规范，并明确提醒，将来的资料可能证明文中部分内容错误。历史写作必须保留这个限制，而不是借后来的清晰措辞制造虚假的完整性。

RFC 8907 描述的是更晚的 TACACS+。它把认证、授权与记账分为三个部分，并指出协议层没有把认证请求与授权请求自动关联。TACACS+ 不是 RFC 927 的 TUID；这里引用它，只为命名一条长期有效的边界：知道对方声称“是谁”，不等于决定“可以做什么”。

能说“不”本身就是互操作能力

RFC 927 允许任意两个同意合作的主机使用 TUID，还以同一站点内的主机为例。它没有建立一个所有主机必须服从的身份中心。共同标准只规范提议、同意、拒绝和编号的线路形式。

IANA Telnet 选项注册表 今天仍把代码 26 记为 TACACS User Identification，并指向 RFC 927。这证明参数分配仍然唯一，避免相同代码被解释成别的功能；它不证明 TUID 当年广泛部署，也不证明今天仍在运行。

DON'T TUID 不是协作失败，而是协作边界。目标能拒绝上游声明，才说明共同语法没有把源主机变成目标的授权主体。协议让信任可以清楚表达，也让不信任可以清楚表达。

少一次输入，需要多保留一层证据

用户立刻获得好处：少输一次密码。目标运营者承担的工作更隐蔽：维护可信源列表，理解每个源的编号空间，保证本地映射正确，并在源端被攻破、换运营者或改账号制度时及时撤销信任。

若日志只写“登录成功”，交易结构就消失了。事后无法区分目标是否检查本地密码、是否接受 TUID、怎样映射账号、是否另做授权，以及应用动作究竟有没有发生。界面简化不能成为审计简化的理由。

完整证据链应把源端认证结果、WILL/DO 协商、TUID 数值与编号空间、目标信任政策、本地账号映射、逐项授权和应用结果分别记录。每一项只证明实际作出那次判断的主体与范围。

RFC 927 没有发明万能数字身份。它留下的是一项更诚实的历史机制：一台主机愿意为自己的认证说话，另一台主机愿意听，重复登录才可省掉。UUID 跨过连接；相信它所需的决定权没有跨过去。

资料与结论边界

本文使用 RFC 854、855、927，IANA Telnet 选项注册表，以及仅作限定比较的 RFC 1492、8907。这些一手资料可以建立语法、文档自述的动机、代码分配和后期概念区分，不能建立部署规模、密码学安全、与现代联合登录的直接血统，或任何实际会话的成功结果。