摘要

  • IDENT 查询的不是全球身份目录。接收连接的一方反向连到对方主机的 TCP 113 端口，用同一对 IP 地址与第一条连接的准确端口对，让对方查本机连接表。
  • 协议名称的收缩揭示了权力边界：1984 年的 Authentication Service、1985 年的 Authentication Server Protocol，到 1993 年改称 Identification Protocol；RFC 1413 明令不得把 USERID 回复当作访问控制标识。
  • USERID、HIDDEN-USER 与 UNKNOWN-ERROR 都是远端主机在自身系统和隐私政策下作出的报告。它可以协助两地管理员对表，却无法证明人的身份、授权或陈述真实性。

一条业务连接，为什么还需要第二条

设想 A 主机从本地端口 6191 连到 B 主机的 Telnet 端口 23。B 看见了来源地址和端口，也许还收到应用层用户名，但它想在日志里留下另一个线索：A 的操作系统把这条连接记在哪个本地用户名下。

B 不修改 Telnet，也不向中央身份库查询。它反向连接 A 的 TCP 113 端口，在这条新连接里发送 6191, 23。顺序以回答者 A 的视角为准：先是 A 的本地端口，再是 B 的远端端口。A 若能在自己的 TCP 状态中找到这组连接，便可返回 USERID、操作系统类型和一个本地标识符。

RFC 1413 规定的正是这种“双连接”结构。第一条连接承载业务，第二条连接追问第一条的本机归属。用户名不是第一条报文自带的身份凭证，而是远端主机查看自身状态后给出的旁证。

查询范围因此受到四元组约束。两端 IP 地址来自第二条 TCP 连接本身，两个端口来自查询文本。它不能列举 A 上的所有用户，也不能询问与 B 无关的连接。问题很窄，但回答的权威也同样窄：A 只能陈述 A 的系统此刻如何关联这一连接。

最初的名字承载了过大的愿望

RFC 912 在 1984 年 9 月把 113 端口上的服务称为 Authentication Service。文档设想 FTP 服务器把应用层提交的用户名，与建立 TCP 连接的用户进行核对；它还讨论了特权操作以及主机之间的信任。

但警告从一开始就存在。接收方必须信任远端主机诚实地维护账户与连接映射，也要信任其本地用户不能操纵回答。假如远端系统已被攻破，或者管理员故意伪报，协议没有独立证据纠正它。

1985 年 1 月发布的 RFC 931 将其正式写成 Authentication Server Protocol，固定了端口对查询、USERID 与 ERROR 回复，还探索了依据返回标识进行本地访问映射的做法。这里呈现的是早期互联网的一种诱人捷径：既然对方主机知道是谁创建连接，应用也许不用再自己识别一次。

问题在于，“知道”只存在于对方系统的账本里。协议没有证明键盘前的人，没有保护回答免受网络或主机欺骗，也没有让两个机构对同一个名字采用相同含义。它传输的是一项本地关联，而不是一份跨机构凭证。

改名是对真实能力的校准

1993 年 2 月，IETF IDENT 工作组发布 RFC 1413，取代 RFC 931，并把名称改为 Identification Protocol。规范明确说，新名称更准确地反映其功能。这不是编辑风格的小改，而是把协议从“认证”退回它真正能做的“标识报告”。

RFC 1413 的安全说明非常直接：返回信息最多用于审计，不得作为访问控制标识。若 B 只因 A 回答 alice 就开放资源，受到控制的 A 完全可以对任何连接都回答 alice。第二条连接没有增加独立信任源，反而可能让接收方把对方可任意生成的字符串错当成自己的授权依据。

这并不使 USERID 毫无价值。B 可以把它与时间、地址、端口和应用日志一起保存。发生滥用时，A 的管理员可以用本地登录、进程和连接记录再做对应。两方因而多了一个寻找同一事件的索引，但最终结论仍需各自系统的证据相互印证。

两个端口的次序就是证据的一部分

端口对最容易在方向切换时写反。A 看第一条连接时，6191 是本地端口、23 是远端端口；B 看同一条连接时，23 是本地、6191 是远端。现在 B 作为查询者连回 A，查询字段必须按回答者 A 的视角填写，所以仍是 6191, 23。

如果写成 23, 6191，A 被要求查的是另一组连接。正确实现应返回 INVALID-PORT 或无法得到有效答案。看似只有两个整数，实际却携带了方向、主机角色和连接时刻。

IP 地址没有重复写在查询行里，而从承载查询的 TCP 连接取得。这减小了文本歧义，却没有形成密码学绑定。普通网络路径仍可能受干扰，回复内容仍由被询问主机生成。

端口还是可复用的临时编号。若日志只留端口对而没有精确时间，同一编号后来可能属于另一条连接。因此可复核记录必须同时保存原连接的地址、端口、方向和时间，以及 IDENT 查询与回复。用户名是序列中的一次观察，不是端口永久拥有者。

USERID 把本地命名空间搬过了边界

成功回复会回显端口对，声明 USERID 类型，给出操作系统类型，再附一个字符串。操作系统字段帮助接收者判断这个标识符来自什么命名规则；可选字符集参数则处理另一层互操作问题：同样的字节能否被双方读成同样的字符。

RFC 1413 还允许操作系统值为 OTHER。此时返回的可以是未格式化令牌，而非传统用户名。协议由此承认：接收者不应擅自把结果理解成 Unix 账户、全球唯一的人或长期稳定的雇员编号。

规范建议提供便于管理员关联的标识，不要无端泄露进程或命令细节。目标是让回答主机日后能认回事件，而不是给远端开启一扇任意查看本机活动的窗口。

错误码也表达隐私政策

INVALID-PORT 表示查询格式或端口范围有误。NO-USER 表示无法为指定连接找到用户。HIDDEN-USER 则更微妙：系统可能知道答案，但策略禁止透露。UNKNOWN-ERROR 让实现不必把内部故障全部暴露；若服务在形成回复前断开连接，查询者也应按 UNKNOWN-ERROR 处理。

这些状态不能互相替代。NO-USER 不能证明连接匿名，HIDDEN-USER 不能证明用户可疑，UNKNOWN-ERROR 也不能证明映射不存在。它们只描述服务在那一刻能够或愿意说什么。

RFC 1413 将隐私问题与 CallerID、Finger 一类服务相比较。一个用户名在本机内部也许平常，但当任何收到连接的远端服务都能反查它时，披露范围已经改变。关闭服务、隐藏用户或返回令牌都可保护隐私，却也改变审计线索的含义。

因此，隐私不是查询成功之后再考虑的附属问题。它直接决定外界能观察到什么。沉默、隐藏和别名，都可能是合规的本地决定。

管理表复制了结构，没有增加证明

RFC 1414 为 Identification Protocol 定义 MIB。表项以本地地址、本地端口、远端地址、远端端口作索引，并暴露用户标识与状态。它把同一套四元组结构搬到网络管理系统，而不是通过 113 端口逐次问答。

RFC 1414 的状态现为 Historic；RFC 编辑器仍将 RFC 1413 列为 Proposed Standard。两种状态不应被误读为当前部署量。来源证明的是规范演变，不是今天有多少主机开放该服务。

MIB 文档同样警告：标识结果并非权威，不得用于访问控制。把一个值放进结构化表格，只会让检索更方便，不会让它更真实。

注册表统一入口，却不担保回答

当前 IANA 服务名称与传输协议端口注册表 在 TCP 113 上同时保留 ident 与旧称 auth。注册让实现者知道到哪里寻找服务，也保留了名称变化的历史痕迹。

IANA 不会认证回复里的用户名。端口注册协调的是会合点，而非回答主机的操作系统、账户库、隐私策略或管理员。公共语法可以统一问题，却不会把每个本地答案变成中央事实。

用户名失去授权力之后，才获得可控价值

IDENT 的要点不是鼓励今天的每个服务都反查 TCP 用户，而是揭示归属线索与访问授权必须是两套动作，即使它们都出现一个像账户名的字符串。

查询有严格范围：同一对主机、按回答者视角排列的端口、特定时刻存在的连接。回复来自握有本地状态的主机。错误码承认不知道，HIDDEN-USER 承认不愿披露，安全章节承认对方可能撒谎。

在这些边界内，回复能减少跨机构排查成本。越过边界，它就成为危险捷径。远端主机报告的用户名，是“远端如此陈述”的证据，不是用户提交的凭证，也不是本地服务必须执行的命令。

协议的标题从 Authentication 走到 Identification，看似降低目标，实际提高了诚实度：规范终于让名称与证据链的真实权力相匹配。

来源与证据边界

这些来源规定了历代协议、管理模型和服务名注册，却没有测量当代部署、回答准确率、隐私实践或攻击频率。本文不声称 IDENT 今天仍被广泛启用，也不推断封闭来源未说明的 NAT、代理或容器行为。