Skip to main content

4. TACACS+ 混淆机制的废弃 (Obsolescence of TACACS+ Obfuscation)

[RFC8907] 第 4.5 节中记录的混淆机制是弱加密机制。

在 TACACS+ 中引入 TLS 身份验证和加密取代了这一旧机制，因此混淆机制在此正式废弃。本节描述 TACACS+ 客户端和服务器必须如何处理混淆机制。

对等方不得 (MUST NOT) 在 TLS 上使用混淆。

发起 TACACS+ TLS 连接的 TACACS+ 客户端必须 (MUST) 设置 TAC_PLUS_UNENCRYPTED_FLAG 位，从而声明该会话不使用混淆。所有后续数据包必须 (MUST) 将 TAC_PLUS_UNENCRYPTED_FLAG 位设置为 1。

TLS TACACS+ 服务器如果通过 TLS 连接收到 TAC_PLUS_UNENCRYPTED_FLAG 位未设置为 1 的数据包，必须 (MUST) 根据 TACACS+ 消息类型返回相应的错误 (TAC_PLUS_AUTHEN_STATUS_ERROR、TAC_PLUS_AUTHOR_STATUS_ERROR 或 TAC_PLUS_ACCT_STATUS_ERROR)，并将 TAC_PLUS_UNENCRYPTED_FLAG 位设置为 1，然后终止会话。

TACACS+ 客户端如果收到 TAC_PLUS_UNENCRYPTED_FLAG 位未设置为 1 的数据包，必须 (MUST) 终止会话，并应该 (SHOULD) 记录此错误。

5. 安全性考虑 (Security Considerations)

5.1. TLS​

本文档通过添加 TLS 支持，提高了 TACACS+ 对等方之间连接和网络流量的机密性、完整性和身份验证。

仅仅向协议添加 TLS 支持并不能保证 TLS TACACS+ 服务器和客户端的保护。运营商和设备供应商必须遵循最新的最佳实践，以确保网络设备的完整性并选择安全的 TLS 密钥和加密算法。

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

5.1.1. TLS 使用 (TLS Use)​

新的 TACACS+ 生产部署应该 (SHOULD) 使用 TLS 身份验证和加密。

TLS TACACS+ 服务器(如第 2 节中定义)不得 (MUST NOT) 允许非 TLS 连接，因为存在第 5.3 节中描述的降级攻击或配置错误的威胁。相反，应该 (SHOULD) 设置单独的非 TLS TACACS+ 服务器来为这些客户端提供服务。

不建议 (NOT RECOMMENDED) 在同一主机上部署 TLS TACACS+ 服务器和非 TLS TACACS+ 服务器，原因在第 5.3 节中讨论。非 TLS 连接最好通过在单独的主机上部署所需的非 TLS TACACS+ 服务器来提供服务。

如果 TLS 连接失败，TACACS+ 客户端不得 (MUST NOT) 回退到非 TLS 连接。此禁止包括在部署迁移期间(第 6.1 节)。

5.1.2. TLS 0-RTT​

TLS 1.3 恢复和 PSK 技术使得发送早期数据(即 0-RTT 数据)成为可能，这些数据在 TLS 握手完成之前发送。重放这些数据存在风险。鉴于 TACACS+ 数据的敏感性，客户端不得 (MUST NOT) 在完整的 TLS 握手完成之前发送数据；也就是说，客户端不得 (MUST NOT) 发送 0-RTT 数据，TLS TACACS+ 服务器必须 (MUST) 立即断开发送 0-RTT 数据的客户端连接。

TLS TACACS+ 客户端和服务器不得 (MUST NOT) 包含 early_data 扩展。有关安全问题，请参见 [RFC8446] 的第 2.3 节和第 4.2.10 节。

5.1.3. TLS 选项 (TLS Options)​

必须 (MUST) 遵循 [BCP195] 中的建议，以确定应该支持、弃用、废弃或放弃哪些 TLS 版本和算法。

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

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

运营商应该意识到 TLS TACACS+ 服务器和/或客户端可能因网络故障而与其对等方的 CA 隔离。与公钥证书的 CA 隔离将导致证书验证失败，从而导致对等方的 TLS 身份验证失败。第 3.4.1 节中提到的方法可以帮助解决这个问题，应该考虑采用。

5.1.5. TLS 服务器名称指示 (SNI) (TLS Server Name Indicator)​

运营商应该意识到 TLS SNI 扩展是 TLS 客户端 hello 的一部分，以明文发送。因此，它容易被窃听。另请参见 [RFC6066] 第 11.1 节。

5.1.6. 服务器身份通配符 (Server Identity Wildcards)​

在 TLS 服务器身份中使用通配符会造成单点故障：通配符证书的私钥被破坏会影响使用它的所有服务器。它们的使用必须 (MUST) 遵循 [RFC9525] 第 7.1 节的建议。运营商必须 (MUST) 确保通配符仅限于专门用于 TLS TACACS+ 服务器的子域。

5.2. TACACS+ 配置 (TACACS+ Configuration)​

实现者必须确保为启用 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 模式指示器
  • 当端口号与配置的模式不匹配时发出验证警告
  • 为 TLS 和非 TLS 服务器分别设置配置部分

5.3. 众所周知的 TCP/IP 端口号 (Well-Known TCP/IP Port Number)​

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

  • 通过 TCP/IP 端口号轻松阻止未混淆或混淆的连接，
  • 监控未混淆的被动入侵检测系统 (IDS) 不受 TLS 引入的影响，
  • 避免可能干扰升级的路径攻击，以及
  • 防止由于配置错误而意外暴露敏感信息。

6. 运营考虑 (Operational Considerations)

6.1. 迁移 (Migration)​

为了促进从传统 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+ 客户端 (Maintaining Non-TLS TACACS+ Clients)​

某些传统设备可能不支持 TLS 且无法升级。对于这些设备，运营商有几个选择：

  1. 单独的非 TLS 基础设施 (Separate Non-TLS Infrastructure): 在单独的主机上部署专用的非 TLS TACACS+ 服务器(推荐)。如果可能，这些服务器应该在更受限制的网络段中隔离。

  2. 逐步硬件更新 (Gradual Hardware Refresh): 计划在正常更新周期中更换或升级传统设备。

  3. 补偿控制 (Compensating Controls): 如果必须保留传统设备，请实施额外的网络级安全控制，例如专用 VLAN、增强监控或网络层的加密隧道。

非 TLS TACACS+ 服务器应该 (SHOULD) 被明确记录和监控。组织应该有完成 TLS 迁移的目标日期。

6.3. TACACS+ 客户端的 YANG 模型 (YANG Model for TACACS+ Clients)​

用于配置 TACACS+ 客户端(包括 TLS 特定参数)的 YANG 数据模型将有利于网络自动化和跨异构网络设备的一致配置管理。

这样的模型可以包括：

  • 服务器地址和端口号
  • TLS 配置参数(证书路径、密码套件等)
  • 回退行为和超时设置
  • 身份验证优先级

标准化 YANG 模型的开发超出了本文档的范围，但鼓励作为未来的工作。在基于 YANG 的管理系统中实现 TACACS+ over TLS 的组织应该考虑开发供应商中立的模型。

7. IANA 考虑 (IANA Considerations)

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

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

8. 致谢 (Acknowledgments)

作者要感谢 IETF 运营和管理领域工作组 (OPSAWG) 参与者的贡献和反馈。特别感谢那些在本规范开发期间提供宝贵意见的人，包括审查、建议和实现经验，这些帮助塑造了本文档。

通过 TLS 增强 TACACS+ 安全性的工作是由运营社区对更好地保护设备管理流量的需求驱动的。作者感谢使本规范成为可能的协作努力。

9. 参考文献 (References)

9.1. 规范性参考文献 (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

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

  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

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

  • [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 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, "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", 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 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.

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

  • [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023.

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

  • [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011.

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

9.2. 信息性参考文献 (Informative References)​

  • [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 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, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014.

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

  • [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016.

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

  • [RFC9257] Housley, R., "Guidance for External Pre-Shared Key (PSK) Usage in TLS", RFC 9257, DOI 10.17487/RFC9257, July 2022.

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

  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (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, "Security Requirements for Cryptographic Modules", FIPS PUB 140-3, March 2019.

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

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

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

作者地址 (Authors' Addresses)​

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]

Last updated on