摘要

  • RFC 5418 将 CAPWAP 无线安全拆成无线终端、AAA 服务、接入控制器和无线终结点之间的多组双边关系；相邻链路各有凭据，并不等于整条链自动具备端到端授权。
  • 使用预共享密钥时，授权可能只到设备类别这一层：持有密钥不一定能区分接入控制器和无线终结点。
  • 可信证书、受保护的控制通道、设备属于某一具体网络，是三个不同事实。设备登记、角色校验、AAA 密钥和实际数据路径都需要分别核验。

制造商签过名，不等于运营方批准接入

设想一台分支机构的无线接入设备出示了由制造商签发的证书。签名正确，硬件也确实来自该厂商。但这仍不能说明设备属于当前运营方的无线部署、应当扮演接入控制器还是无线终结点，也不能确定它能进入哪个网络分区。签名验证成功只回答了其中一项问题。

RFC 5418 提供了观察这一边界的具体模型。它发表于 2009 年，属于 Informational 文档，分析 CAPWAP 将一个传统接入点拆为两个网络元素后带来的暴露面：处于无线边缘的 Wireless Termination Point（WTP）和位于其他位置的 Access Controller（AC）。原先在一台设备内部发生的交互，现在要经过三层网络。文档指出，安全性取决于中间网络，也取决于控制器与终结点之间如何划分工作。

这个研究范围很明确：它是针对 CAPWAP 与 IEEE 802.11 部署的威胁分析，不是产品部署普查、事故调查，也不是互联网标准。它的重要价值在于把一组常被架构图压成一个“安全”标签的问题拆开：对端是谁、它获准执行什么角色、密钥交给了谁、客户端数据真正走哪条路？

本文借用 Heng Lu 第 65 条笔记《Running-Code Primacy》作为编辑方法：把声明和实际运行的系统、运营者能验证的证据对照起来。这条笔记讨论互联网协调系统的设计，并不是无线安全规范。在这里，它只是提醒我们，协议框图和政策文本不能代替对现行证书、角色检查、控制器关系和数据转发路径的核查。

CAPWAP 增加了新的信任边

传统接入点用一台设备连接无线终端与有线网络。CAPWAP 将工作分开：WTP 负责无线侧收发，AC 负责控制器侧管理及有线侧功能。这样的分工方便集中管理，也适用于不同的远程站点结构；代价是多出若干信任关系。

RFC 5418 的简化例子至少包含七组关系或密钥流转：

步骤 关系或交付 在例子中建立的事实
1 WTP–AC CAPWAP 对等关系
2 AC–AAA 控制器与认证服务之间经过认证的链路
3 终端–AAA EAP 认证并产生密钥材料
4 AAA → AC 向控制器交付 Pairwise Master Key
5 AC–终端 生成临时密钥材料的四次握手
6 AC → WTP 使用分散式加密时，向 WTP 交付临时密钥
7 WTP–终端 终端的无线链路安全

这不是一次覆盖全路径的握手。RFC 5418 明确把它们视为双边信任关系。终端信任 AAA、AAA 信任 AC、AC 信任 WTP，并不能自动推出终端也应当信任该 WTP。被攻陷的 WTP 可能继续维持与 AC 的关系，却向终端提供误导性的网络信息。信任层级中的一个设备出问题，也可能影响其下游。

这是体系结构上的风险说明，并非断言所有网络都遭到攻击。审查重点是沿着每个身份和每把密钥追到它授予的权限，并判断被攻陷的节点能利用这些权限做什么。

共享密钥能证明什么，仍留下什么

RFC 5418 区分认证与授权。认证要回答对端能否证明身份或凭据持有权；授权要回答它能访问哪些资源、可以执行哪些操作。

对预共享密钥，文档指出授权可能宽泛而粗粒度：知道密钥的设备会被视为属于某个可信类别。为不同设备类别配置不同密钥可以提供一些区分，但类别密钥本身仍未必能证明持有者是 AC 还是 WTP。若两个角色使用同一密钥，拿到密钥的一方就可能声称自己是其中任意一种，除非另有校验。

当密钥的传播范围超过设备台账时，风险会变大。一个密钥如果出现在工厂预置、上线准备记录、控制器配置和替换设备流程中，它就不再只属于一台设备，而成为共享的运营能力。风险取决于谁能读取它、设备类别是否真的隔离、密钥如何轮换，以及接收方是否检查声明的角色。RFC 5418 没有说任何具名运营商采用了这些做法；这些是需要运营方回答的控制问题。

证书可以支持更细的检查，但“有证书”并不等于完整的登记策略。RFC 5418 讨论了包含设备 MAC 地址的主体名称，以及用来区分 AC 和 WTP 的 Extended Key Usage 位。只有在接收方核实名称是否属于本次部署、并严格执行角色用途时，这些字段才有帮助。如果接受过于宽泛的任意扩展用途，角色边界可能随之消失，除非还有额外的名称校验。

制造商签发的证书能说明凭据的签发来源，却不等于客户组织已经把设备登记进自己的网络。WTP 应该信任哪一台 AC？AC 应该接受哪些 WTP？RFC 5418 特别指出，证书授权和零接触配置并不完全兼容。它假设 WTP 能识别正确的 AC、AC 能识别正确的 WTP，而没有分析如何建立这项选择。采购与安全审查不应把这条前提藏起来。

AAA 是另一处必须明确的控制权

在简化模型中，AC 扮演认证器，并通过 RADIUS 或 Diameter 与 AAA 服务器通信。RFC 5418 警告，AC–AAA 链路若使用非唯一或低熵的长期凭据，会严重影响整个 CAPWAP 部署的安全；它建议使用相互认证、具备机密性和完整性的链路，并引用 RFC 4962 的 AAA 密钥管理指导。

这项建议保护的是与 WTP–AC 不同的边。有效的 WTP–AC DTLS 会话不会自动验证 AC 所连接的 AAA 服务器。终端与 AAA 之间采用强 EAP 方法，也不代表只有预期控制器能收到后续密钥材料。无线握手完成，更不能证明密钥被交给了正确的 WTP。运营方需要给每个凭据和授权决定指定负责人。

这也是组织设计问题。无线团队可能负责设备入网，安全团队负责证书策略，身份团队负责 AAA。每个团队都可以说自己的链路受到保护，但如果无人核对链路之间如何衔接，整体信任仍然悬空。有效的记录应把每一条关系连到凭据签发方、验证方、设备角色和部署成员证据。

控制隧道不等于客户端数据路径

身份与密钥流转不是全部架构。RFC 5418 区分控制消息和用户数据转发，讨论 Split MAC、Local MAC 等模式。在 Local MAC 场景下，大部分 MAC 工作由 WTP 完成，数据帧通常在站点本地桥接。CAPWAP 的模式名称并不能严格规定每种数据隧道行为。

RFC 5415 给出协议层面的边界：为发现候选控制器，Discovery Request 与 Discovery Response 保持明文；其他 CAPWAP 控制消息必须使用 DTLS。数据包是否受到保护则是可选项，由 AC 策略决定。因此，一个安全的控制关系并不能证明客户端数据经过 AC、使用了独立受保护的数据通道，或在本地进入有线网。

不同选择会改变执行控制的位置。集中转发可让控制器成为政策执行点，但也延长数据路径并增加依赖。就地桥接可免去把所有流量送回远端控制器，却会把分段、检查和监控责任更多地推到边缘设备及所连接的有线网络。这些是架构取舍，不是普遍建议。需要验证的，是实际路径是否与政策、监控和事故响应预案一致。

加密也不能消除所有威胁。RFC 5418 讨论资源耗尽、被动观察、流量分析以及中间人丢弃数据包等情况。它还指出 DHCP 或 DNS 冒充、ARP 缓存投毒等问题超出 CAPWAP 本身的保护范围。这些边界不等于 DTLS 没用，而是说明保护覆盖到哪里、还需要谁负责其他防线。

可执行的审查应当跟踪关系图

一份有用的 CAPWAP 审查应从真实拓扑出发，回答以下问题：

  1. 每台 WTP 会接受哪些 AC？怎样证明这些控制器属于本次部署？
  2. 每台 AC 会接受哪些 WTP？怎样区分设备角色？
  3. 如果使用预共享密钥，验证方能否区分 AC 与 WTP，并确认凭据只用于预期部署？
  4. AC 和 WTP 实际执行哪些证书名称及角色用途检查？证书有效但设备不在本地允许清单里时会发生什么？
  5. AC 用什么凭据认证 AAA？密钥交付和授权记录保存在哪里？
  6. 客户端数据经过 AC 还是在本地桥接？加密、分段、检查和日志位于哪一段？
  7. DTLS 仍未消除哪些风险：资源耗尽、流量分析、丢包干预、发现过程操纵，或邻接 LAN 攻击？

这些问题能把“无线网络使用证书”拆成可核实的判断。替换接入点时要更新设备清单和角色授权，不能只确认制造商签名。把分支迁移到本地桥接时，政策执行和监控计划也要跟随数据包移动。轮换 AC–AAA 密钥不应意外摧毁 WTP–AC 身份关系，也不应封死备用路径。

不把旧文档当作今天的证明

RFC 5418 是 2009 年 CAPWAP 与 802.11 安全设计的分析。它的密码学示例和术语不应直接作为今日配置建议。RFC 5415 定义 CAPWAP 协议，RFC 5418 分析拆分接入点功能带来的暴露。两者都没有证明今天某个厂商交付什么、某张网络怎样配置，或是否发生过事故。

它留下的分析原则更窄：受保护的链路只是信任图中的一条边。真正要问的不是有几条边上了锁，而是每个被接受的身份是否对应正确的部署、角色和权限，以及客户端数据是否走了组织以为自己管理的路径。持有凭据与掌控凭据开启的系统不是一回事。

来源