跳到主要内容

5. 认证 (Authentication)

联邦 (federation) 内建立的所有通信都使用带相互认证 (mutual authentication) 的 TLS 1.3 [RFC8446]. 该机制确保通信双方的真实性, 为安全数据交换建立稳健基础.

5.1. 公钥固定 (Public Key Pinning)​

MATF 基于 [RFC7469] 实现公钥固定 (public key pinning). 公钥固定会将一个或多个公钥固定项 (public key pin) 与每个联邦端点关联起来. 这些固定项发布在联邦元数据中. 在连接期间, 客户端和服务器从提交的证书中提取公钥, 并验证该公钥是否匹配从联邦元数据中检索到的预配置公钥固定项.

5.1.1. 公钥固定的益处 (Benefits of Public Key Pinning)​

在 MATF 框架中采用公钥固定的决定, 是由若干旨在增强安全性并确保信任的关键因素驱动的.

5.1.1.1. 联邦间信任 (Interfederation Trust)​

在联邦间 (interfederation) 环境中, 多个联邦需要彼此信任, 公钥固定仍然有效. 成员可以使用通过共享元数据发布的固定项来验证其他联邦中的实体, 从而确保跨边界的信任. 私有证书链在多个联邦之间可能变得复杂且难以管理, 而公钥固定提供了一种直接的信任建立机制. MATF 联邦间机制通过将所有参与联邦的元数据聚合到统一的元数据仓库 (metadata repository) 中来解决这一挑战. 这种共享元数据支持不同联邦中的实体之间进行安全通信, 确保一致的密钥验证, 以及稳健的跨联邦信任和安全性.

5.1.1.2. 加固安全性以抵御威胁 (Fortifying Security Against Threats)​

公钥固定通过将对等方直接绑定到特定公钥, 提供稳健的防御机制. 这确保只有指定密钥受信任, 防止攻击者利用欺诈性证书. 通过消除对外部信任中介的依赖, 这种方法显著增强了抵御潜在威胁的能力.

5.1.1.3. 使用自签名证书 (Use of Self-Signed Certificates)​

联邦内使用自签名证书 (self-signed certificate) 时, 会利用公钥固定来建立信任. 通过绕过外部证书颁发机构 (Certificate Authority, CA), 服务器和客户端依赖联邦机制来验证信任. 公钥固定确保只有由元数据中的密钥固定项标识的特定自签名公钥受信任.

5.1.1.4. 吊销 (Revocation)​

在依赖证书链和证书吊销机制的部署中, 吊销可能复杂且缓慢. 出现这种复杂性是因为一个不再可信的证书, 以及链中可能存在的其他证书, 可能都需要被吊销并重新签发. 公钥固定允许客户端基于固定的公钥而不是证书链作出信任决策, 从而缓解这种复杂性.

如果 MATF 联邦内某个公钥不再可信, 则移除关联的固定项. 随后发布更新后的元数据. 更新后的元数据包含一个新的固定项, 对应替换证书中的公钥. 这种方法减少了对证书吊销机制的依赖, 并将信任关系转移到由其固定项标识的特定更新公钥上.

5.2. 固定项发现与预加载 (Pin Discovery and Preloading)​

联邦中的对等方从联邦元数据中获取公钥固定项. 这些固定项作为用于验证的预配置信任参数, 如第 5.3 节所规定.

联邦 MUST 定义发现规则. 这些规则描述对等方如何使用联邦元数据声明, 例如 organization 和 tags, 来标识相关端点及其固定项.

在发起或接受连接之前, 对等方 MUST 从其本地元数据存储中预加载所选端点或已授权端点的固定项. 本地元数据存储的维护, 包括刷新行为和过期处理, 在第 4.2 节中规定.

为支持对等方标识, 预加载状态 MUST 能够将派生固定项映射到对应的 entity_id. 这可以通过维护一个本地索引来实现, 该索引将每个预加载的固定项值映射到其关联的 entity_id.

服务器 MAY 仅预加载满足服务器连接策略的客户端固定项, 例如基于 organization 或 tags. 固定项验证会按第 5.3 节中的规定强制执行由此产生的策略.

5.3. 接收证书的验证 (Verification of Received Certificates)​

建立连接后, 两个端点 MUST 验证所提交对等方证书中的公钥是否匹配联邦元数据中发布的某个固定项. 该验证 MAY 由 TLS 栈执行, 也 MAY 由应用程序逻辑执行.

在由中介终止 TLS 会话的架构中, 固定项验证 MUST 由中介或应用程序执行. 如果应用程序执行固定项验证, 中介 MUST 将对等方证书或派生固定项转发给应用程序. 应用程序 MUST 能够根据转发的信息和联邦元数据确定对等方 entity_id. 该解析依赖第 6.1.1.1 节规定的客户端固定项摘要唯一性属性.

如果中介执行固定项验证, 它 MUST 将对等方证书, 派生固定项或 entity_id 传播给应用程序, 以支持授权.

中介与应用程序之间的通道 MUST 受到完整性保护, 并且 MUST 提供端点认证.

为此目的传送的任何证书, 固定项或身份 MUST 直接从 TLS 会话派生. 实现 MUST NOT 从对等方提供的应用程序数据中接受这些值.

如果实现允许禁用默认的基于 CA 的证书链验证, 则在仍然强制执行固定项验证的同时, 它 SHOULD 这样做. 如果需要链验证, 用于证书链验证的信任锚 MUST 从联邦元数据中列出的签发者中选择.

如果未找到与某个对等方匹配的固定项, 则连接 MUST 按第 5.4 节处理.

5.4. 验证失败 (Failure to Validate)​

接收到的证书如果验证失败, MUST 导致连接立即终止. 这包括派生固定项不匹配任何预加载固定项, 或无法解析对等方身份的场景. 这种严格执行确保联邦内只建立已授权且安全的通信通道.

5.5. 证书轮换 (Certificate Rotation)​

无论是由于过期还是其他原因而替换证书, 都 MUST 遵循以下流程:

  1. 提交更新后的元数据: 当证书计划轮换时, 联邦成员提交更新后的元数据, 在已经发布的固定项旁添加新公钥的固定项. 联邦运营者重新发布签名后的联邦元数据聚合, 使所有联邦成员都可以获得新的固定项.

  2. 传播期: 联邦成员 MUST 按第 4.2 节中的规定刷新其本地元数据存储. 执行轮换的成员在切换到新证书之前, MUST 留出足够时间, 以便对等方刷新并预加载新的固定项.

  3. 切换到新证书: 传播期结束后, 执行轮换的成员更新其 TLS 栈, 以提交新证书. 这使已经预加载新固定项的对等方能够验证轮换后的证书.

  4. 移除旧固定项: 成功过渡后, 执行轮换的成员 MUST 提交更新后的元数据, 其中排除旧固定项. 联邦运营者重新发布聚合, 确保联邦内只有当前公钥保持受信任状态.

5.6. 实现指南 (Implementation Guidelines)​

固定项验证的位置取决于部署架构. 对于客户端, 验证通常由发起 TLS 连接的组件执行. 对于使用中介的服务器, 中介与应用程序之间的通信通道 MUST 受到完整性保护, 以防止转发的对等方身份材料被篡改.

当中介使用 HTTP 头部字段传播对等方身份材料, 例如对等方证书, 派生固定项或 entity_id 时, 这些头部字段就是用于满足第 5.3 节所规定要求的机制. 对于为此目的使用的每个头部字段名称, 中介 MUST 移除从对等方收到的该头部字段的任何实例, 然后自行设置该头部字段值. 这确保应用程序只处理直接从 TLS 会话派生的身份材料, 从而使应用程序能够将对等方匹配到联邦元数据, 并基于联邦元数据声明应用授权策略. 不用于传送身份材料的头部字段不受此要求影响. 中介与应用程序之间的通信通道 MUST 提供完整性保护和端点认证, 以防止转发的对等方身份材料被篡改.

实现 SHOULD 在可能时依赖内置支持固定的库. 例如, libcurl 通过 CURLOPT_PINNEDPUBLICKEY 选项支持固定. 在 Python 中, cryptography 库可以提取公钥, 应用程序代码可以将派生固定项与配置值进行比较. Go 提供 crypto/tls 和 crypto/x509, 用于证书检查和公钥提取. 在 Java 中, java.security.cert.X509Certificate 支持公钥提取, 而 java.net.http.HttpClient 允许使用自定义 SSLContext 和 TrustManager 来强制执行固定. 库的选择由每个实现自行决定.