文章总结： RFC9887定义TACACS+overTLS1.3以增强AAA协议安全性，废弃原有弱混淆机制，要求相互认证和加密，并指定新端口号。 综合评分： 85 文章分类： 网络安全,技术标准,应用安全
基于TLS 1.3的终端访问控制器访问控制系统增强版（TACACS+）
衡水石头哥 衡水石头哥
铁军哥
2026年7月21日 07:42 北京
在小说阅读器读本章
去阅读
RFC9887：Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3，December 2025
梗概
本文档指定使用传输层安全性（Transport Layer Security，TLS）版本1.3来保护终端访问控制器访问控制系统增强版（Terminal Access Controller Access-Control System Plus，TACACS+）客户端和服务器之间的通信通道。TACACS+ 是一种用于网络环境中的身份验证、授权和计费（Authentication, Authorization, and Accounting，AAA）的协议。原始TACACS+ 协议不强制要求使用加密或安全传输。该规范定义了将TLS 1.3与TACACS+ 结合使用的配置文件，包括有关身份验证、连接建立和运维注意事项的指南。目标是增强TACACS+ 流量的机密性、完整性和真实性，使协议与现代安全最佳实践保持一致。
本文档更新了RFC 8907。
本备忘录的状态
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc9887。
版权声明
版权所有（c）2025 IETF Trust和文档作者。版权所有。
本文件受本文件发布之日生效的BCP 78和IETF信托与IETF文件相关的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括《信托法律条款》第4.e节中所述的修订版BSD许可证文本，并且不提供修订版BSD许可证中所述的保证。
1、简介
“终端访问控制器访问控制系统增强版（Terminal Access Controller Access-Control System Plus，TACACS+）协议”[RFC8907] 通过一个或多个集中式TACACS+ 服务器为路由器、网络访问服务器和其他联网计算设备提供设备管理。该协议为设备管理用例中的TACACS+ 客户端提供身份验证、授权和计费服务（authentication, authorization, and accounting，AAA）。
协议的内容高度敏感，需要安全传输来保护部署。然而，TACACS+缺乏对TACACS+服务器和客户端之间的连接和网络流量的有效机密性、完整性和身份验证。 [RFC8907] 第4.5节中描述的安全机制非常薄弱。
为了解决这些缺陷，本文档更新了TACACS+ 协议以使用TLS 1.3身份验证和加密 [RFC8446]，并废弃了TACACS+ 混淆机制的使用。TLS在1.3及以上版本的成熟使其成为TACACS+协议的合适选择。
2、技术定义
[RFC8907]第3节中定义的术语完全适用于此，不再重复。本文档中还使用了以下术语。
混淆：TACACS+ 最初旨在纳入一种保护数据包主体的机制。该算法在 [RFC8907] 的第10.5.2节中被归类为混淆。该术语用于确保算法不会被误认为是加密。它不应该被认为是安全的。
非TLS连接：该术语指的是 [RFC8907] 中定义的连接。这是一个没有TLS的连接，使用不安全的TACACS+ 身份验证和混淆（或用于测试的未混淆选项）。使用众所周知的TCP/IP主机端口号49被指定为非TLS连接的默认端口。
TLS连接：TLS连接是一种TCP/IP连接，采用TACACS+ 进行传输时使用的TLS身份验证和加密。TACACS+ 的TLS连接始终位于一台TACACS+ 客户端和一台TACACS+ 服务器之间。
TLS TACACS+ 服务器：本文档描述了TACACS+ 服务器的一个变体，在 [RFC8907] 的3.2节中介绍，它利用TLS进行传输，并进行了一些相关的协议优化。两种服务器变体都响应TACACS+ 流量，但本文档特别将TACACS+ 服务器（无论是TLS还是非TLS）定义为绑定到特定IP地址或主机名上的特定端口号。此定义在TACACS+ 客户端配置上下文中非常重要，可确保它们将流量定向到正确的TACACS+ 服务器。
对等体：TACACS+ 连接上下文中TACACS+ 客户端（或服务器）的对等体是TACACS+ 服务器（或客户端）。TACACS+ 连接的两端统称为对等体。
2.1、要求语言
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。
3、基于TLS的TACACS+
TACACS+ over TLS采用 [RFC8907] 中定义的协议，删除了混淆选项，并指定使用TLS 1.3进行传输（第3.1节详细介绍了TLS版本支持）。使用新的众所周知的默认主机端口号。接下来的部分将提供更多详细信息和指导。
TACACS+中引入TLS是为了满足以下要求：
-
机密性和完整性：[RFC8907]中指定的混淆机制底层的MD5算法在用于加密时已被证明是不安全的[RFC6151]。这会阻止在符合 [FIPS-140-3] 的部署中使用TACACS+。使用TLS保护TACACS+ 协议的目的是在不需要提供安全网络的情况下提供机密性和完整性。
-
对等身份验证：TLS的身份验证功能取代了混淆的共享秘密以进行相互身份验证。
本文档遵循 [REQ-TLS13] 中的建议。
3.1、分离TLS连接
实现本文档中定义的TACACS+ 协议变体的对等体必须应用相互身份验证并加密它们之间交换的所有数据。因此，当为服务建立TCP连接时，TLS握手立即开始。不得使用升级初始非TLS连接的选项；参见第5.3节。
为了确保使用TLS的TACACS+ 流量与不使用TLS的TACACS+ 流量之间的明确分离（请参阅第5.3节），支持基于TLS的TACACS+ 的服务器必须侦听与非TLS TACACS+ 服务器使用的端口不同的TCP/IP端口。进一步建议在单独的主机上部署TLS和非TLS服务，如第5.1.1节中所述。
鉴于现有TACACS+ 客户端实现中默认端口使用的普遍性，本规范为基于TLS的TACACS+ 分配了众所周知的TCP端口号300（请参阅第7节）。
虽然强烈鼓励使用指定端口号，但具有特定要求的部署可以使用替代TCP端口号。在这种情况下，运维人员必须仔细考虑第5.3节中描述的运营影响。
3.2、TLS连接
TACACS+ 客户端通过与TACACS+ TLS端口号上配置的TLS TACACS+ 服务器建立TCP连接来启动TLS连接。一旦TCP连接建立，客户端必须立即开始TLS协商，然后再发送任何TACACS+ 协议数据。
传输必须至少使用TLS 1.3 [RFC8446]。正如本文档中所述，预计TACACS+ 将与未来版本的TLS配合使用。不得使用早期版本的TLS。
一旦成功建立TLS连接，TACACS+ 数据的交换必须按照 [RFC8907] 中定义的过程进行。然而，所有TACACS+ 消息均应作为TLS应用数据传输。当通过TLS（第4节）进行操作时，不得应用 [RFC8907] 中定义的TACACS+ 混淆机制。
TLS TACACS+ 连接通常不是长期存在的。如果遇到错误或不活动超时，连接将被对等体关闭。
对于不在单连接模式下运行的连接（如 [RFC8907] 第4.3节中定义），TCP会话应在关联的TACACS+ 会话完成后关闭。在单连接模式下运行的连接可能会持续较长时间，但通常会在短暂不活动后超时并关闭。因此，不需要支持传输层保活机制。
连接关闭的原因与TLS恢复无关，除非因TLS错误而关闭，在这种情况下，票证可能已失效。
除了IPv4之外，TACACS+ 客户端和服务器还广泛支持IPv6配置。本文件未对该领域的建议进行任何更改。
3.3、TLS身份验证选项
实现必须支持基于证书的相互身份验证，为部署之间的互操作性提供核心选项。该认证选项在第3.4节中指定。
除了基于证书的TLS身份验证之外，实现还可以支持以下替代身份验证机制：
* 预共享密钥（Pre-Shared Keys，PSK）（第3.5节），在TLS 1.3中也称为外部PSK。
* 原始公钥（Raw Public Keys，RPK）。RPK的详细信息不属于本文档的范围。有关实现、部署和安全注意事项，请参阅 [RFC7250] 和 [RFC8446] 的第4.4.2节。
3.4、基于TLS证书的身份验证
TLS证书身份验证是基于TLS的TACACS+ 的主要身份验证选项。本节仅涵盖基于证书的身份验证。
正确部署基于TLS证书的身份验证将显着提高TACACS+ 部署的安全性。实现者和运维人员必须了解基于TLS证书的身份验证解决方案的含义，包括正确处理证书、证书颁发机构（Certificate Authorities，CA）以及TLS配置的所有元素。如需指导，请从 [BCP195] 开始。
每个对等体必须验证其远程对等体的证书路径，包括吊销检查，如第3.4.1节中所述。
如果验证成功，则认证成功，允许连接。策略可以对对等体施加进一步的约束，根据证书字段或实现公开的任何其他参数来允许或拒绝连接。
除非通过配置禁用，否则对等体不得允许任何提供无效TLS证书的对等体的连接。
3.4.1、TLS证书路径验证
基于证书的相互身份验证的实现必须支持证书路径验证，如 [RFC5280] 第6节中所述。
在某些部署中，对等体可能与远程对等体的CA隔离。这些部署的实现必须支持证书链（又名捆绑包或信任链），其中远程对等体的证书的整个链都存储在本地对等体上。
应实现TLS缓存信息扩展 [RFC7924]。这可以通过RPK [RFC7250] 进行增强，但必须处理撤销，因为它不是该规范的一部分。
可以使用其他方法将中间证书加载到客户端，但它们必须包括对吊销检查的支持。例如，[RFC5280]详细介绍了权威信息访问（Authority Information Access，AIA）扩展，以提供有关该扩展出现的证书颁发者的信息。它可用于提供在线证书状态协议（Online Certificate Status Protocol，OCSP）响应程序的地址，从中可以检查证书（包括扩展）的吊销状态。
3.4.2、TLS证书识别
对于所提供的TLS TACACS+ 服务器身份的客户端验证，实现必须遵循 [RFC9525] 中定义的验证技术。标识符类型DNS-ID、IP-ID或SRV-ID适用于TLS TACACS+ 协议；它们由运维人员根据部署设计进行选择。TLS TACACS+ 不使用URI-ID进行TLS TACACS+ 服务器身份验证。
TLS TACACS+ 服务器身份中的通配符允许单个证书保护部署中的多个服务器，从而简化了证书管理。但是，这会带来安全风险，因为通配符证书的私钥泄露会影响使用它的所有服务器。为了解决这些风险，必须遵循 [RFC9525] 第6.3节中的指南，并且通配符应该限制在专门用于TACACS+ 服务器的子域中。
对于客户端身份的TLS TACACS+ 服务器端验证，实现必须支持配置证书的哪些字段用于客户端身份验证的功能，以验证客户端是否是所接收证书的有效源以及是否允许其访问TACACS+。实现必须支持：
* [RFC5425] 第5.2节中描述的基于网络地址的验证方法或
* 证书subjectAltName中共享身份的客户端身份验证。这适用于客户端安全支持与TLS TACACS+ 服务器共享的身份的部署。必须支持dNSName和iPAddress的匹配。可能支持 [RFC5280] 第4.2.1.6节中定义的其他选项。这种方法允许重新配置客户端的网络位置，而无需颁发新的客户端证书。
实现必须支持TLS服务器名称指示（Server Name Indication，SNI）扩展（[RFC6066] 第3节）。TLS TACACS+ 客户端必须支持配置TLS TACACS+ 服务器域名的功能，以便它可以包含在客户端hello的SNI“server_name”扩展中（这与用于TCP连接的IP地址或主机名配置不同）。请参阅第5.1.5节了解与安全相关的运维人员注意事项。
证书配置超出了本文档的范围。
3.4.3、密码套件要求
实现必须支持TLS 1.3强制密码套件（[RFC8446] 的第9.1节）。读者应参考[BCP195]。提供或接受的密码套件应该是可配置的，以便运维人员能够适应。
3.5、TLS PSK身份验证
作为基于证书的身份验证的替代方案，实现可以支持PSK，在TLS 1.3 [RFC8446] 中也称为外部PSK。这些不应与恢复PSK混淆。
与基于证书的身份验证相比，外部PSK的使用不太成熟。建议系统遵循 [RFC9257] 和 [RFC8446] 第4节的指示。
在实施PSK身份验证的情况下，必须支持至少16个八位位组的PSK长度。
PSK身份必须遵循 [RFC9257] 第6.1节的建议。实现必须支持至少16个八位位组的PSK身份。
尽管本文档删除了混淆选项（第4节），但组织中仍然可能存在TACACS+ 的TLS和非TLS版本，例如在迁移期间（第6.1节）。在这种情况下，为TACACS+ 混淆客户端配置的共享密钥不得与为TLS客户端配置的PSK相同。
3.6、TLS恢复
TLS恢复 [RFC8446] 可以最大限度地减少握手过程中所需的往返次数。如果TLS客户端持有先前从TLS TACACS+ 服务器的NewSessionTicket消息中提取的票证，则它可以使用与该票证绑定的PSK身份。如果TLS TACACS+ 服务器同意，恢复的会话将被确认为已通过身份验证并安全链接到初始会话。
当客户端持有来自TLS TACACS+ 服务器的有效未使用票证时，应使用恢复，因为每个票证仅供单次使用，并将在恢复期间刷新。TLS TACACS+ 服务器可以拒绝恢复请求，但如果相关票证尚未过期且之前未使用过，则TLS TACACS+ 服务器应该允许恢复。
当TLS TACACS+ 服务器收到来自TLS客户端的恢复请求时，它仍然可以选择要求完全握手。在这种情况下，协商将继续进行，就像会话是新的身份验证一样，并且恢复尝试将被忽略。如 [RFC8446] 的附录C.4中所述，票证的重用允许被动观察者关联不同的连接。TLS TACACS+ 客户端和服务器应该遵循 [RFC8446] 附录C.4中的客户端跟踪预防措施。
在处理TLS恢复时，必须验证证书以检查自上次NewSessionTicket消息以来的时间段内证书是否被吊销。
恢复ticket_lifetime应该是可配置的，包括零秒的票据有效期。有关票证有效期的指导，请参阅 [RFC8446] 的第4.6.1节。
4、TACACS+混淆的废弃
[RFC8907] 4.5节中记录的混淆机制很弱。
TACACS+ 中引入的TLS身份验证和加密取代了以前的机制，因此混淆已被废弃。本节描述TACACS+ 客户端和服务器必须如何针对混淆机制进行操作。
对等体不得使用TLS进行混淆。
发起TACACS+ TLS连接的TACACS+ 客户端必须设置TAC_PLUS_UNENCRYPTED_FLAG位，从而断言会话不使用混淆。所有后续数据包必须将TAC_PLUS_UNENCRYPTED_FLAG位设置为1。
通过TLS连接接收TAC_PLUS_UNENCRYPTED_FLAG位未设置为1的数据包的TLS TACACS+ 服务器必须根据TACACS+ 消息类型返回TAC_PLUS_AUTHEN_STATUS_ERROR、TAC_PLUS_AUTHOR_STATUS_ERROR或TAC_PLUS_ACCT_STATUS_ERROR错误，其中TAC_PLUS_UNENCRYPTED_FLAG位设置为1，并终止会话。此行为对应于 [RFC8907] 第4.5节中定义的有关TAC_PLUS_UNENCRYPTED_FLAG或密钥不匹配的数据混淆的行为。
接收到TAC_PLUS_UNENCRYPTED_FLAG位未设置为1的数据包的TACACS+ 客户端必须终止会话，并且应该记录此错误。
5、安全考虑
5.1、TLS
本文档通过添加TLS支持改进了TACACS+ 对等体之间连接和网络流量的机密性、完整性和身份验证。
简单地向协议添加TLS支持并不能保证对TLS TACACS+ 服务器和客户端的保护。运维人员和设备供应商必须遵守最新的最佳实践，以确保网络设备的完整性并选择安全的TLS密钥和加密算法。
[BCP195] 为实施和部署使用TLS的协议提供了大量指导。实施和部署安全TACACS+ 的人员必须遵守 [BCP195] 或其后续版本中概述的与TLS 1.3相关的建议。
本文件概述了 [BCP195] 允许的其他限制。例如，任何涉及TLS 1.2的建议（包括强制支持）都与Secure TACACS+ 无关，因为强制要求使用TLS 1.3或更高版本。
本文档涉及使用TLS作为TACACS+ 的传输，除了弃用混淆的直接影响之外，没有对核心TACACS+ 协议进行任何更改。运维人员必须认识到TACACS+ 协议本身的安全影响。例如，计划进一步制定文件，以解决基于密码的身份验证的安全隐患，并增强协议以适应替代方案。
5.1.1、TLS使用
新的TACACS+ 生产部署应使用TLS身份验证和加密。另请参阅 [RFC3365]。
TLS TACACS+ 服务器（如第2节中定义）不得允许非TLS连接，因为存在第5.3节中描述的降级攻击或错误配置的威胁。相反，应该设置单独的非TLS TACACS+ 服务器来满足这些客户端的需求。
出于第5.3节中讨论的原因，不建议将TLS TACACS+ 服务器和非TLS TACACS+ 服务器部署在同一主机上。通过在单独的主机上部署所需的非TLS TACACS+ 服务器，可以更好地为非TLS连接提供服务。
如果TLS连接失败，TACACS+ 客户端不得故障回退到非TLS连接。此禁止包括部署迁移期间（第6.1节）。
5.1.2、TLS 0-RTT
TLS 1.3恢复和PSK技术使得发送早期数据（也称为0-RTT数据）、在TLS握手完成之前发送的数据成为可能。重放此数据存在风险。考虑到TACACS+ 数据的敏感性，在完整的TLS握手完成之前客户端不得发送数据；也就是说，客户端不得发送0-RTT数据，并且TLS TACACS+ 服务器必须突然断开发送0-RTT数据的客户端。
TLS TACACS+ 客户端和服务器不得包含“early_data”扩展。有关安全问题，请参阅 [RFC8446] 的第2.3节和第4.2.10节。
5.1.3、TLS选项
必须遵循 [BCP195] 中的建议来确定应支持、弃用、废弃或放弃哪些TLS版本和算法。
此外，[RFC8446] 第9节规定了强制支持的选项。
5.1.4、无法访问的证书颁发机构（CA）
运维人员应该认识到TLS TACACS+ 服务器和/或客户端因网络故障而与其对等CA隔离的可能性。与公钥证书的CA隔离将导致证书验证失败，从而导致对等体的TLS身份验证失败。第3.4.1节中提到的方法可以帮助解决这个问题，应该予以考虑。
5.1.5、TLS服务器名称指示器（SNI）
运维人员应注意，TLS SNI扩展是TLS客户端问候的一部分，以明文形式发送。因此，它会受到窃听。另请参阅 [RFC6066] 的第11.1节。
5.1.6、服务器身份通配符
在TLS服务器身份中使用通配符会造成单点故障：通配符证书的私钥受损会影响使用它的所有服务器。它们的使用必须遵循 [RFC9525] 第7.1节的建议。运维人员必须确保通配符仅限于专用于TLS TACACS+ 服务器的子域。此外，运维人员必须确保通配符证书覆盖的TLS TACACS+ 服务器不会将流量重定向到其他服务器（例如，由于路径攻击或DNS缓存中毒）。
5.2、TACACS+配置
实现者必须确保为启用TLS引入的配置方案简单明了，并且在TACACS+ 客户端和TACACS+ 服务器之间使用TLS还是非TLS时不存在任何歧义。
本文档建议使用TLS TACACS+ 服务器将侦听的单独端口号。如果部署没有显式覆盖默认值，TACACS+ 客户端实现必须使用正确的端口值：
* 49：用于非TLS连接TACACS+
* 300：用于TLS连接TACACS+
实现者可以为TACACS+ 客户端和服务器提供单个选项来禁用所有非TLS TACACS+ 操作。在TACACS+ 服务器上启用时，它将不会响应来自非TLS TACACS+ 客户端连接的任何请求。在TACACS+ 客户端上启用时，它不会建立任何非TLS TACACS+ 服务器连接。
5.3、众所周知的TCP/IP端口号
新的端口号被认为是合适的（而不是从初始非TLS TACACS+ 连接协商升级的机制），因为它允许：
* 通过TCP/IP端口号轻松阻止未混淆或混淆的连接，
* 被动入侵检测系统（Intrusion Detection Systems，IDS）监控未混淆的内容，使其不受TLS引入的影响，
* 避免可能干扰升级的路径攻击，以及
* 防止因配置错误而意外泄露敏感信息。
然而，劣质身份验证和混淆的共存，无论是非TLS连接还是构成TLS的已弃用部分，也为降级攻击提供了机会。导致启用TLS的服务连接失败或共享算法支持协商失败是两种此类降级攻击。
针对非TLS连接方法的最简单的缓解措施是完全拒绝主机上的非TLS连接，可能对非TLS连接和TLS使用单独的主机。
另一种方法是需要TLS的相互配置。TACACS+ 客户端和服务器应该支持要求对等体（全局和单独）使用TLS的配置。此外，对等体应该可配置，以将提供或认可的TLS版本和算法限制为标准机构和实现者推荐的版本和算法。
6、运维注意事项
操作和部署注意事项贯穿整个文档。在避免重复的同时，对于不耐烦的人来说，特别注意第5.2节和第5.1.5节是很有用的。然而，重要的是遵守整个第5节。
运维人员必须了解基于TLS证书的身份验证解决方案的含义，包括正确处理证书、CA和TLS配置的所有元素。请参阅 [BCP195] 获取指导。请注意向所有对等体（包括TACACS+ TLS客户端）提供证书，以允许强制相互身份验证。
6.1、迁移
第5.2节提到，为了实现TLS TACACS+ 的最佳部署，应在整个部署过程中普遍应用TLS。但是，在从非TLS TACACS+ 部署迁移过程中，运维人员可能需要同时支持TLS和非TLS TACACS+ 服务器。这一迁移阶段允许运维人员逐渐将其部署从不安全状态过渡到更安全的状态，但需要注意的是，它很容易受到降级攻击。因此，迁移阶段在完全完成之前应被视为不安全。为了减轻这种危险：
* 应尽量缩短任何客户端同时配置TLS和非TLS TACACS+ 服务器的时间。
* 如上所述，运维人员必须考虑支持TLS和非TLS连接的安全影响。
6.2、维护非TLS TACACS+ 客户端
部署中的某些TACACS+ 客户端设备可能未实现TLS。这些设备将需要访问非TLS TACACS+ 服务器。运维人员必须遵循第5.1.1节的建议，并为这些非TLS客户端部署与用于TLS客户端的服务器分开的非TLS TACACS+ 服务器。
6.3、TACACS+ 客户端的YANG模型
[TACACS-YANG] 指定用于管理TACACS+ 客户端的YANG模型，包括TLS支持。
7、IANA考虑因素
IANA在“服务名称和传输协议端口号注册表”中分配了以下新的众所周知的系统（请参阅https://www.iana.org/assignments/service-names-port-numbers）。服务名称“tacacss”遵循通常的做法，即在非TLS知名端口名称的名称后面附加“s”。请参阅第5.3节中的分配理由。
服务名称：tacacss
端口号：300
传输协议：TCP
描述：TLS安全登录主机协议（TACACSS）
受让人：IESG
联系人：IETF主席
参考：RFC 9887
有关服务发现的考虑超出了本文档的范围。
8、参考文献
8.1、规范性参考文献
[BCP195] Best Current Practice 195, <https://www.rfc-editor.org/info/bcp195>. At the time of writing, this BCP comprises the following:Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.[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>.[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>.[RFC5425] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed., "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, DOI 10.17487/RFC5425, March 2009, <https://www.rfc-editor.org/info/rfc5425>.[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>.[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., 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>.[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.C., Carrel, 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>.[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>.
8.2、参考资料
[FIPS-140-3] NIST, "Security Requirements for Cryptographic Modules", NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.140-3.pdf>.[REQ-TLS13] Salz, R. and N. Aviram, "New Protocols Using TLS Must Require TLS 1.3", Work in Progress, Internet-Draft, draftietf-uta-require-tls13-12, 14 April 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-utarequire-tls13-12>.[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <https://www.rfc-editor.org/info/rfc3365>.[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>.[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, <https://www.rfc-editor.org/info/rfc9190>.[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood, "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>.[RFC9813] DeKok, A., "Operational Considerations for Using TLS PreShared Keys (TLS-PSKs) with RADIUS", BCP 243, RFC 9813, DOI 10.17487/RFC9813, July 2025, <https://www.rfc-editor.org/info/rfc9813>.[TACACS-YANG] Boucadair, M. and B. Wu, "A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)", Work in Progress, Internet-Draft, draft-ietf-opsawgsecure-tacacs-yang-13, 7 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawgsecure-tacacs-yang-13>.
9、致谢
作者要感谢Russ Housley、Steven M. Bellovin、Stephen Farrell、Alan DeKok、Warren Kumari、Tom Petch、Tirumal Reddy、Valery Smyslov和Mohamed Boucadair的支持、富有洞察力的评论和/或评论。 [RFC5425] 也被用作TLS通用方法的基础。 [RFC9190] 被用作TLS恢复建议的基础。尽管在撰写本文时仍处于草案形式，[RFC9813] 已被用作PSK建议的模型。
***推荐阅读***
我们的WireGuard管理系统支持手机电脑了！全平台终端配置，支持扫码连接，一键搞定
保姆级教程：一条命令部署OpenVPN管理系统V4版，支持Win/Mac/安卓/iOS全平台接入
成本省下99.7%！用40元的腾讯云服务器自建IPsecVPN，成功对接企业级飞塔防火墙
终极进化：当swanctl遇上FRR，让你的Linux加密隧道化身SD-WAN雏形
流量指哪打哪！手把手教你用静态Segment List玩转SRv6流量工程
嫌SRv6报文太胖跑不动？带你在Ubuntu+FRR实战uSID微段压缩
22秒跑出密码！算力碾压再升级，揭秘WiFi6+WPA3的致命短板
嫌一键部署不过瘾？带你手搓Hermes智能体，主打一个通透
十倍性能提升！Ubuntu 26.04深度实测：当VPP遇上OpenVPN，带宽直接冲破 6.5Gbps！
性能暴涨670 %！当WireGuard遇上VPP，带宽直冲7.4 Gbps！
手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台
2048卡昇腾910C集群算力集群交付工程手册
2048卡H100算力中心100G无阻塞存储网建设方案
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：铁军哥 衡水石头哥 衡水石头哥《基于TLS 1.3的终端访问控制器访问控制系统增强版（TACACS+）》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论