跳到主要内容

4. TACACS+ 混淆的废止

[RFC8907] 第 4.5 节中记录的混淆机制较弱.

向 TACACS+ 引入 TLS 认证和加密后, 取代了这一旧机制, 因此 混淆在此被废止. 本节描述 TACACS+ 客户端和服务器在混淆机制方面 MUST 如何运行.

对等方 MUST NOT 将混淆与 TLS 一起使用.

发起 TACACS+ TLS 连接的 TACACS+ 客户端 MUST 设置 TAC_PLUS_UNENCRYPTED_FLAG bit, 从而声明本会话未使用混淆. 后续所有 packet MUST 将 TAC_PLUS_UNENCRYPTED_FLAG bit 设置为 1.

TLS TACACS+ 服务器如果在 TLS 连接上收到 TAC_PLUS_UNENCRYPTED_FLAG bit 未设置为 1 的 packet, MUST 根据 TACACS+ message type 返回 TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR, 或 TAC_PLUS_ACCT_STATUS_ERROR 中适当的错误, 并将 TAC_PLUS_UNENCRYPTED_FLAG bit 设置为 1, 然后终止会话.

TACACS+ 客户端如果收到 TAC_PLUS_UNENCRYPTED_FLAG bit 未设置为 1 的 packet, MUST 终止会话, 并且 SHOULD 记录此错误.

5. 安全考虑

5.1. TLS​

本文档通过增加 TLS 支持, 提升 TACACS+ 对等方之间连接和网络流量的机密性, 完整性, 以及认证能力.

仅向协议增加 TLS 支持, 并不能保证 TLS TACACS+ 服务器和客户端受到保护. 运营方和设备供应商必须遵循最新最佳实践, 以确保网络设备的完整性, 并选择安全的 TLS key 和 encryption algorithm.

[BCP195] 为实现和部署使用 TLS 的协议提供了大量指导. 实现和部署 Secure TACACS+ 的人员必须遵守 [BCP195] 或其后续版本中与 TLS 1.3 相关的建议.

5.1.1. TLS 使用​

新的 TACACS+ 生产部署 SHOULD 使用 TLS 认证和加密.

TLS TACACS+ 服务器 (如第 2 节所定义) MUST NOT 允许非 TLS 连接, 因为第 5.3 节描述了降级攻击或配置错误的威胁. 相反, 应设置单独的非 TLS TACACS+ 服务器来服务这些客户端.

出于第 5.3 节讨论的原因, NOT RECOMMENDED 将 TLS TACACS+ 服务器和非 TLS TACACS+ 服务器部署在同一主机上. 对于非 TLS 连接, 更好的做法是在独立主机上部署所需的非 TLS TACACS+ 服务器.

如果 TLS 连接失败, TACACS+ 客户端 MUST NOT 回退到非 TLS 连接. 此禁止要求也适用于部署迁移期间 (第 6.1 节).

5.1.2. TLS 0-RTT​

TLS 1.3 resumption 和 PSK 技术使发送 early data 成为可能, 也称为 0-RTT data, 即在 TLS handshake 完成之前发送的数据. 重放这些数据是一种风险. 鉴于 TACACS+ 数据的敏感性, 客户端 MUST NOT 在完整 TLS handshake 完成之前发送数据; 也就是说, 客户端 MUST NOT 发送 0-RTT data, 并且 TLS TACACS+ 服务器 MUST 突然断开这样做的客户端.

TLS TACACS+ 客户端和服务器 MUST NOT 包含 "early_data" extension. 有关安全顾虑, 请参见 [RFC8446] 第 2.3 节和第 4.2.10 节.

5.1.3. TLS 选项​

MUST 遵循 [BCP195] 中的建议, 以确定应支持, 弃用, 废止, 或放弃哪些 TLS 版本和算法.

此外, [RFC8446] 第 9 节规定了强制支持的选项.

5.1.4. 无法访问的证书颁发机构 (CA)​

运营方应认识到, 网络故障可能导致 TLS TACACS+ 服务器和/或客户端与其对等方的 CA 隔离. 与 public key certificate 的 CA 隔离会导致证书验证失败, 从而导致对等方的 TLS 认证失败. 第 3.4.1 节提到的方法可以帮助解决这一问题, 应予以考虑.

5.1.5. TLS Server Name Indicator (SNI)​

运营方应注意, TLS SNI extension 是 TLS client hello 的一部分, 而 TLS client hello 以明文发送. 因此, 它可能被窃听. 另请参见 [RFC6066] 第 11.1 节.

5.1.6. 服务器身份通配符​

在 TLS 服务器身份中使用通配符会形成单点故障: 通配符证书的 private key 一旦泄露, 将影响使用该证书的所有服务器. 其使用 MUST 遵循 [RFC9525] 第 7.1 节的建议. 运营方 MUST 确保通配符仅限于专门用于 TLS TACACS+ 服务器的子域.

5.2. TACACS+ 配置​

实现者必须确保为启用 TLS 而引入的配置方案直观明确, 并且不会在 TACACS+ 客户端和 TACACS+ 服务器之间将使用 TLS 还是非 TLS 这一点上留下歧义.

本文档建议使用一个单独的端口号, 供 TLS TACACS+ 服务器监听. 在部署未显式覆盖默认值的情况下, TACACS+ 客户端实现 MUST 使用正确的端口值:

  • 端口 49: 用于非 TLS 连接 TACACS+
  • 端口 300: 用于 TLS 连接 TACACS+

实现者可以为 TACACS+ 客户端和服务器提供一个单一选项, 用于禁用所有非 TLS TACACS+ 操作. 在 TACACS+ 服务器上启用该选项时, 服务器不会响应来自非 TLS TACACS+ 客户端连接的任何请求. 在 TACACS+ 客户端上启用该选项时, 客户端不会建立任何非 TLS TACACS+ 服务器连接.

一种常见的配置错误是在服务器上启用 TLS, 但将客户端错误配置为使用非 TLS 端口, 或反过来. 为防止这种情况, 清晰的配置实践 SHOULD 包括:

  • 配置文件中显式的 TLS/非 TLS mode indicator
  • 当端口号与配置的模式不匹配时给出 validation warning
  • 为 TLS 和非 TLS 服务器使用单独的配置节

5.3. 知名 TCP/IP 端口号​

采用新的端口号被认为是合适的 (而不是采用从初始非 TLS TACACS+ 连接协商升级的机制), 因为它允许:

  • 通过 TCP/IP 端口号轻松阻止未混淆或已混淆的连接,
  • 使监视未混淆流量的被动 Intrusion Detection Systems (IDSs) 不受 TLS 引入的影响,
  • 避免可能干扰升级的 on-path attack, 以及
  • 防止因配置错误而意外暴露敏感信息.

6. 运维考虑

6.1. 迁移​

为促进从旧式 TACACS+ 部署平滑过渡到由 TLS 保护的 TACACS+, 组织需要仔细规划迁移. 最常见的迁移策略包括:

并行运行 (Parallel Operation): 运营方可以在现有非 TLS 服务器旁部署新的 TLS TACACS+ 服务器. 这允许逐步迁移客户端而不中断服务. 但是, 如第 5.1.1 节所述, NOT RECOMMENDED 在同一主机上同时运行 TLS 和非 TLS 服务.

分阶段迁移 (Phased Migration): 推荐方法包括:

  1. 评估阶段 (Assessment Phase): 识别环境中的所有 TACACS+ 客户端和服务器
  2. 试点阶段 (Pilot Phase): 在测试环境中于端口 300 部署 TLS TACACS+ 服务器
  3. 初始部署 (Initial Deployment): 配置一部分客户端使用新的 TLS 服务器
  4. 逐步推出 (Gradual Rollout): 逐步迁移更多客户端
  5. 监控期 (Monitoring Period): 确保运行稳定后再继续推进
  6. 完成 (Completion): 在所有客户端迁移完成后停用非 TLS 基础设施

迁移期间, 如果 TLS 连接失败, TACACS+ 客户端 MUST NOT 被配置为回退到非 TLS 连接 (第 5.1.1 节). 此禁止要求对于防止降级攻击至关重要.

运营方应在迁移期间保留详细日志, 以识别仍在尝试非 TLS 连接的任何客户端.

6.2. 维护非 TLS TACACS+ 客户端​

某些旧式设备可能不支持 TLS, 且无法升级. 对于这些设备, 运营方有几种选择:

  1. 单独的非 TLS 基础设施 (Separate Non-TLS Infrastructure): 在独立主机上部署专用的非 TLS TACACS+ 服务器 (RECOMMENDED). 如有可能, 这些服务器应隔离在限制更严格的网段中.

  2. 逐步硬件更新 (Gradual Hardware Refresh): 计划在常规更新周期内替换或升级旧式设备.

  3. 补偿性控制 (Compensating Controls): 如果旧式设备必须保留, 则实施额外的网络层安全控制, 例如专用 VLAN, 增强监控, 或网络层的 encrypted tunnel.

非 TLS TACACS+ 服务器 SHOULD 被清晰记录并受到监控. 组织应设定完成 TLS 迁移的目标日期.

6.3. TACACS+ 客户端的 YANG 模型​

用于配置 TACACS+ 客户端的 YANG data model, 包括 TLS 特定参数, 将有助于网络自动化以及跨异构网络设备的一致配置管理.

此类模型可以包括:

  • 服务器地址和端口号
  • TLS 配置参数 (certificate path, cipher suite 等)
  • fallback 行为和 timeout 设置
  • 认证优先级

标准化 YANG 模型的开发超出本文档范围, 但鼓励将其作为未来工作. 在基于 YANG 的管理系统中实现 TACACS+ over TLS 的组织, 应考虑开发 vendor-neutral model.

7. IANA 考虑

IANA 已为 TACACS+ over TLS 分配 TCP 端口号 300, 服务名称为 "tacacss":

Service Name: tacacss
Transport Protocol: TCP
Port Number: 300
Description: TACACS+ over TLS
Reference: RFC 9887

8. 致谢

作者感谢 IETF Operations and Management Area Working Group (OPSAWG) 参与者的贡献和反馈. 特别感谢在本规范制定过程中提供宝贵意见的人员, 包括评审, 建议, 以及帮助塑造本文档的实现经验.

通过 TLS 增强 TACACS+ 安全性的工作, 源于运维社区对设备管理流量提供更好保护的需求. 作者感谢使本规范成为可能的协作努力.

9. 参考文献

9.1. 规范性参考文献​

  • [RFC2119] Bradner, S., "用于在 RFC 中指示要求级别的关键词", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

    • https://www.rfc-editor.org/info/rfc2119

  • [RFC8174] Leiba, B., "RFC 2119 Key Words 中大写与小写的歧义", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

    • https://www.rfc-editor.org/info/rfc8174

  • [RFC8446] Rescorla, E., "传输层安全 (TLS) 协议版本 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.

    • https://www.rfc-editor.org/info/rfc8446

  • [RFC8907] Dahm, T., Ota, A., Medway Gash, D., and L. Grant, "Terminal Access Controller Access-Control System Plus (TACACS+) 协议", RFC 8907, DOI 10.17487/RFC8907, September 2020.

    • https://www.rfc-editor.org/info/rfc8907

  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 公钥基础设施证书和证书撤销列表 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.

    • https://www.rfc-editor.org/info/rfc5280

  • [RFC9525] Saint-Andre, P. and R. Salz, "TLS 中的服务身份", RFC 9525, DOI 10.17487/RFC9525, November 2023.

    • https://www.rfc-editor.org/info/rfc9525

  • [RFC6066] Eastlake 3rd, D., "传输层安全 (TLS) 扩展: 扩展定义", RFC 6066, DOI 10.17487/RFC6066, January 2011.

    • https://www.rfc-editor.org/info/rfc6066

9.2. 资料性参考文献​

  • [RFC6151] Turner, S. and L. Chen, "MD5 Message-Digest 和 HMAC-MD5 算法的更新安全考虑", RFC 6151, DOI 10.17487/RFC6151, March 2011.

    • https://www.rfc-editor.org/info/rfc6151

  • [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "在传输层安全 (TLS) 和数据报传输层安全 (DTLS) 中使用 Raw Public Key", RFC 7250, DOI 10.17487/RFC7250, June 2014.

    • https://www.rfc-editor.org/info/rfc7250

  • [RFC7924] Santesson, S. and H. Tschofenig, "传输层安全 (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016.

    • https://www.rfc-editor.org/info/rfc7924

  • [RFC9257] Housley, R., "TLS 中外部预共享密钥 (PSK) 使用指南", RFC 9257, DOI 10.17487/RFC9257, July 2022.

    • https://www.rfc-editor.org/info/rfc9257

  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "安全使用传输层安全 (TLS) 和数据报传输层安全 (DTLS) 的建议", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.

    • https://www.rfc-editor.org/info/rfc7525

  • [FIPS-140-3] National Institute of Standards and Technology, "密码模块安全要求", FIPS PUB 140-3, March 2019.

    • https://csrc.nist.gov/publications/detail/fips/140/3/final

  • [REQ-TLS13] Moriarty, K. and S. Farrell, "弃用 TLS 1.0 和 TLS 1.1", RFC 8996, DOI 10.17487/RFC8996, March 2021.

    • https://www.rfc-editor.org/info/rfc8996

作者地址​

Thorsten Dahm
Email: [email protected]

John Heasley
NTT
Email: [email protected]

Douglas C. Medway Gash
Cisco Systems, Inc.
Email: [email protected]

Andrej Ota
Google Inc.
Email: [email protected]

最后于 更新