摘要

  • 1985 年的 RFC 933 提出 Telnet 选项 27 OUTMRK：服务器发送一次安全横幅，用户端 Telnet 在应用程序之外持续维护它。
  • WILL/DO 只确认双方采用这一选项；具体横幅仍要由接收端以 ACK 或 NAK 回答，剩余屏幕空间也由接收端安排。
  • 可见标记不是安全政策本身。协议没有认证标记、授予权限、执行强制访问控制，也不能证明用户的物理屏幕始终正确显示了它。

一台服务器想让远端用户始终看到某项安全标记，最直接的办法是把横幅放进应用输出：刷新一屏，重画一次。问题也随之出现。服务器必须知道远端页面大小，应用内容和安全提示争抢相同的光标位置，任何清屏或换页都可能把标记一起抹掉。

S. Silverman 在 1985 年 1 月发布的 RFC 933 把这项职责拆开。文件名为 Output Marking Telnet Option，它建议服务器只发送一次横幅和位置指令，让靠近实际显示设备的 User-Telnet 保存标记、腾出版面并重映射应用光标。

选项名称是 OUTMRK，编号 27。今天的 IANA Telnet Options 名录 仍把 27 对应到 Output Marking 与 RFC 933。这个登记解决的是编号冲突，不是标记的真伪。编号没有说明横幅来自哪个安全权威，也没有说明用户可以做什么。

先同意使用机制，再判断具体横幅

RFC 933 沿用 RFC 854 的选项协商。WILL OUTMRK 表示愿意发送标记信息，DO OUTMRK 表示愿意接收；WON'T 与 DON'T 表示拒绝。默认状态就是不交换标记。

这一步建立的是能力与会话约定，不是对任意横幅的空白授权。双方完成 WILL/DO 后，服务器才发送 IAC SB OUTMRK CNTL data IAC SE。CNTL 指定位置，data 是 ASCII 横幅。

接收端随后面对第二个问题：这条标记能否接受？满意时，它发送包含 ASCII ACK（数值 6）的 OUTMRK 子协商；有异议时发送 NAK（数值 21）。收到 NAK 后，服务器可以换一条“更可接受”的内容重新开始，也可以采取其他行动，RFC 甚至把终止连接列为可能结果，但没有规定唯一处置。

RFC 855 为这种结构提供了通用解释：先用 DO/WILL 同意讨论某组选项参数，再在 SB/SE 中交换参数；之后仍可用 WON'T 或 DON'T 退出。于是 DO、横幅 ACK 和应用访问决定是三个不同事件。

即便 ACK 已经出现，它的范围也很窄：User-Telnet 接受这批数据显示为标记。它不证明服务器给会话分配了正确安全级别，不证明用户有相应许可，不证明随后一条命令被授权，更不证明屏幕硬件此后一直保留横幅。

接收端不再只是字符水管

确认横幅后，User-Telnet 必须把使用光标控制的应用输出映射到“应用区”。安全标记占据一部分屏幕，其余区域才交给远端程序。服务器省掉了反复绘制，也把持续维护的责任交给客户端。

位置控制暴露了方案的边缘。D 让客户端自行选择位置，文件预计多数交互使用这一模式；T 与 B 分别指定顶部和底部。L 与 R 想表达左右两侧，但 RFC 直接承认它们的精确含义尚未定义。一个共同选项编号并不能消除终端几何差异。

横幅可以用 CRLF 分行；多个标记可以放在同一子协商里，用 ASCII Group Separator 分隔，每一项都有自己的位置标志。定位仍由客户端负责。窗口大小变化、终端模式切换、应用清屏或光标寻址错误，都可能让应用区覆盖标记。

这说明线上 ACK 与屏幕事实不能合并。一份抓包可以证明接收端答应了某条横幅，却不能证明调整窗口后横幅仍在，也不能证明用户看见、理解或相信它。真正的呈现证据必须来自客户端状态或显示层观测。

RFC 933 也设计了退出。服务器发送 WON'T OUTMRK 即可终止标记；用户端可用 DO 主动请求，若完成 WILL/DO 后迟迟收不到标记数据，还可用 DON'T 放弃。必要时，客户端把新的有效页面尺寸通知服务器。显示控制不是单向命令，而是一组可拒绝、可终止的分布式责任。

标记描述安全上下文，不执行安全上下文

RFC 933 的动机引用了美国国防部 Trusted Computer System Evaluation Criteria 中“人可读输出标记”的要求。NIST 保存的官方档案版 DoD 5200.28-STD 于 1985 年 12 月发布，晚于 RFC 933，并取代了 RFC 当时引用的 1983 年版本，因此不能用来倒推协议设计细节。

但它保留了一条有价值的制度边界：人可读输出标记与强制访问控制是分开的要求。前者要求标记正确代表输出敏感性，覆盖默认标记的行为可审计；后者才负责基于主体、客体与设备的标签实施访问决定。

RFC 933 只提供远端显示约定，不是完整 Trusted Computing Base。ASCII 横幅没有签名、消息认证码、时间戳、重放保护、可信通道绑定或安全级别命名空间。OUTMRK 语法正确，只说明字节被当作某次标记提议；标记是否真实，要追溯到分配安全上下文的系统、会话关联和可信显示路径。

横幅仍然有用。它可以提醒用户当前会话处于哪个环境，揭示意外级别，减少把不同敏感度内容混在一起的风险。只是这种作用来自“政策分配—横幅生成—协议接受—本地呈现”的完整链，而不是屏幕上几个醒目字符天然拥有权力。

一次发送节省了重复，也转移了保管责任

方案的效率很清楚：服务器不再把标题写进每一屏，也不必知道每种设备的行数。代价同样清楚：客户端要保存横幅、保护区域、改写光标行为、处理多重标记、响应 NAK，并在几何变化后继续维持边界。

若日志只写“OUTMRK 已启用”，最关键的事实仍然丢失：服务器提出了哪条横幅；客户端接受了哪一条；放在何处；是否持续存在；横幅背后的安全级别由谁分配；之后的访问决定依据什么规则。

因此，审计链至少包含六步：权威系统分配上下文；服务器生成文字；Telnet 两端协商能力；客户端接受或拒绝具体文字；显示引擎维护版面；独立访问控制批准或拒绝应用动作。用户最终看到的屏幕，是这些步骤共同产生的结果。

RFC 933 的历史价值不在于证明远程安全标记已经解决，而在于展示一条今天仍容易被忽略的界线：把政策提示送到界面，只完成了第一段交接。接收端要保管呈现，执行端要保管权限，任何一条 ACK 都不能替它们做完全部工作。

来源与证据边界

本文使用 RFC 933、RFC 854、RFC 855、IANA Telnet Options 名录 与 NIST 官方档案中的 DoD 5200.28-STD。它们可以证明提议语法、制度动机，以及显示标记与访问控制在制度上的区别；不能证明普遍部署、当前支持、产品合规、真实机密会话、正确呈现、用户理解或任何实际操作结果。