摘要

  • RFC 9887 为基于 TLS 的 TACACS+ 划出独立服务边界，要求 TLS 1.3 与双向认证，禁止 0-RTT 应用数据，也禁止安全连接失败后回退到非 TLS。
  • 新旧服务可在过渡阶段并存，但规范明确把这一阶段视为尚未安全；旧服务器可达，并不能证明受保护服务获得了连续性。

安全迁移中最重要的句子，往往不是怎样开启新通道，而是新通道不可用时怎么办。RFC 9887给 TACACS+ 的答案很明确：TLS 连接失败时，客户端不得回退到非 TLS，迁移期间也不例外。

这条规则针对的是设备管理控制面。RFC 8907把认证、授权与记账分开，但历史报文体机制只是混淆，不是现代安全传输。RFC 9887 用 TLS 的认证与加密替代受保护版本中的旧机制；它不是在同一个含混监听器上增加一个可选开关。

两条路必须真的分开

TCP 建立后应立即开始 TLS 握手，不得先开非 TLS 会话再就地升级。安全服务与旧服务必须使用不同端口：若没有明确覆盖，旧 TACACS+ 使用 TCP 49，新 tacacss 服务使用 TCP 300。IANA 服务与端口登记保存了这项分配。

分离本身是一项控制。网络策略可以区分两类流量，中间人不能通过干扰升级协商迫使对端留在弱模式，配置含混导致敏感数据误送的概率也会降低。规范还建议使用不同主机。不能实现 TLS 的存量客户端可以访问专门的旧服务器，但该服务器不是 TLS 客户端的隐形备用线路。

端口监听只证明一个传输入口存在。它不证明到达预期对端，不证明协商了合格版本，不证明证书链通过，也不证明握手结束、TACACS+ 请求被接受、授权作出或设备动作发生。这些事实应有不同记录与负责人。

握手成功不替代授权结果

本配置最低要求 TLS 1.3，旧版本不得使用。当前 TLS 1.3 规范是 RFC 9846，安全部署还应遵守 RFC 9325。实现必须支持基于证书的双向认证，作为共同互操作选项。

双方依照 X.509 配置验证对端证书路径与吊销状态，服务身份则参考 RFC 9525。验证成功说明 TLS 对端身份通过。此后，本地政策仍可增加连接条件，TACACS+ 也仍需独立判断具体用户或命令能做什么。

所以，有效证书不是命令授权；完成握手不是记账记录；授权回复成功也不证明命令已经执行，更不证明设备最终状态符合预期。传输认证保护自己的边界，但不继承后续每一层的解释权。

RFC 9887 也禁止提前发送 TACACS+ 应用数据。双方不得带 early_data 扩展，服务器遇到 0-RTT 数据应断开客户端。恢复票据可以帮助建立下一条认证连接，却不能授权在新握手完成前提交可能被重放的 AAA 输入。

故障不能改写规则

禁止回退，是为了阻止一次可用性事件暗中变成政策变更。证书可能过期或被吊销，信任链可能不全，CA 或吊销服务可能因网络隔离而不可达，安全监听器也可能故障。这些都会制造真实压力，却没有一项能把旧服务器重新解释为合格的安全对端。

连续性因此必须在同一证据标准下建设：多个安全服务器、本地可用的证书链、可工作的吊销方案、经过演练的轮换、独立监控与带外恢复。组织可以设计由人批准、有范围、有时限、可审计的例外；它不能让例外以客户端内部无记录的重试分支出现。

并存期不是完成状态

RFC 9887 承认迁移中可能同时保留新旧服务，但也明确指出：迁移完成之前，这一阶段仍不安全；客户端同时配置两类服务器的时间应尽可能短。

“九成客户端已经迁移”并不等于“控制面已有九成安全”。残余弱路径仍可能承载敏感流量，攻击者甚至会故意让 TLS 路径失败，以诱发对弱路径的使用。完成迁移需要证明已迁移客户端不能悄悄回到 49 端口，残留旧服务器只服务一个被明确隔离的群体。

还有几项依赖不能隐藏。SNI 在客户端初始消息中仍是明文；通配符证书把同一私钥的失败面扩大到多个服务器，应限制在 TACACS+ 专用子域；服务发现不在规范范围内。它们都不是机构权威的自动答案，而是本地治理必须接住的输入。

来源