Appendix B. 先例 (Prior Art)

本节为非规范性内容.

本文的建议抽象自大量应用协议规范中的建议.为便于比较, 并说明 IETF 内部关于应用服务身份验证思路的历史演进, 本资料性附录汇集了多个 RFC 中的先例.以下内容以中文概述这些先例中的关键规则, 并保留原协议名称、引用编号和示例标识符.

B.1. IMAP、POP3 和 ACAP (1999)

[USINGTLS] 在 1999 年为 IMAP、POP3 和 ACAP 规定了服务器身份检查.核心要求是: TLS 协商期间, 客户端必须把自己理解的服务器主机名与服务器 Certificate 消息中呈现的身份进行比较, 以防止中间人攻击.匹配规则包括:

客户端必须使用打开连接时使用的服务器主机名作为比较值, 禁止使用从不安全远程来源派生出的任何主机名形式, 例如不安全 DNS 查询.不会执行 CNAME 规范化.
如果证书中存在 dNSName 类型的 subjectAltName 扩展, 应使用它作为服务器身份来源.
匹配不区分大小写.
"*" 通配符可以作为证书中最左侧名称组件使用.例如, *.example.com 匹配 a.example.com 和 foo.example.com, 但不匹配 example.com.
如果证书包含多个名称, 例如多个 dNSName 字段, 任一字段匹配即可接受.

如果匹配失败, 客户端应请求用户明确确认, 或终止连接并指出服务器身份可疑.

B.2. HTTP (2000)

[HTTP-TLS] 在 2000 年规定了 HTTP 中的服务器身份处理.HTTP/TLS 请求通常由解引用 URI 产生, 因而客户端知道服务器主机名.如果主机名可用, 客户端必须将其与服务器 Certificate 消息中呈现的身份比较, 以防止中间人攻击.

如果客户端有外部信息可确定服务器的预期身份, 可以省略主机名检查, 例如客户端连接到地址和主机名动态变化的机器, 但已知服务器将呈现的证书.即便如此, 也必须尽量缩小可接受证书范围.特殊情况下客户端可能忽略服务器身份, 但这会使连接暴露给主动攻击.

证书中如果有 dNSName 类型的 subjectAltName 扩展, 必须将其用作身份.否则, 必须使用证书 Subject 字段中最具体的 Common Name.Common Name 用法虽为既有实践, 但已被弃用, 并鼓励认证机构改用 dNSName.匹配使用 [PKIX-OLD] 的规则.如果同一类型存在多个身份, 任一匹配即可.名称可包含通配符 "*", 它匹配单个域名组件或组件片段, 例如 .a.com 匹配 foo.a.com, 不匹配 bar.foo.a.com; f.com 匹配 foo.com, 不匹配 bar.com.

如果 URI 使用 IP 地址而非主机名, 证书必须包含 iPAddress subjectAltName, 且必须与 URI 中 IP 精确匹配.主机名与证书身份不匹配时, 面向用户的客户端必须通知用户或以错误证书错误终止连接; 自动化客户端必须记录错误, 并应终止连接.规范还指出, 如果 URI 本身来自不受信来源, 该检查不能防止来源被篡改的攻击.

B.3. LDAP (2000/2006)

[LDAP-TLS] 在 2000 年要求客户端将自己理解的服务器主机名与服务器 Certificate 消息中呈现的身份比较.客户端必须使用打开 LDAP 连接时使用的服务器主机名, 禁止使用服务器规范 DNS 名称或其他派生名称.若存在 dNSName subjectAltName, 应作为服务器身份来源.匹配不区分大小写, "*" 通配符只允许作用于最左侧名称组件.若同一类型有多个身份, 任一匹配即可.匹配失败时, 面向用户的客户端应通知用户或终止连接; 自动化客户端应关闭连接并返回或记录错误.客户端还应准备执行额外检查, 确保服务器被授权提供所观察到的服务.

[LDAP-AUTH] 在 2006 年进一步引入 "参考身份 (reference identity)" 概念.客户端确定参考身份类型, 例如 DNS 名称或 IP 地址, 然后与相应类型的每个 subjectAltName 值比较, 直到产生匹配.客户端可在比较前把参考身份映射到不同类型, 但映射必须本身安全, 或通过安全方式完成, 例如使用 [DNSSEC] 或用户/管理员配置的查找表.

LDAP 还允许通过将参考身份与服务器证书 subject 字段最后一个 RDN 中的 Common Name 值比较来验证服务器身份, 其中 "最后" 指 DER 编码顺序.该比较使用 DNS 名称比较规则, 但不允许通配符.Common Name 用法虽为既有实践, 但已弃用, 认证机构被鼓励提供 subjectAltName 值.对于国际化域名, 实现必须先转换为 ACE 格式再与 dNSName 比较.IP 地址参考身份必须转换为网络字节序八位串, 再与 iPAddress subjectAltName 精确比较.实现也可以支持其他 subjectAltName 类型的匹配.

B.4. SMTP (2002/2007)

[SMTP-TLS] 在 2002 年指出, 是否相信 TLS 协商另一方的真实性属于本地事项, 但 SMTP 客户端通常只希望认证服务器证书中域名与客户端认为自己正在连接的域名一致的 SMTP 服务器.

[SMTP-AUTH] 在 2006 年规定, 成功完成 [TLS] 协商后, 客户端必须把自己理解的服务器主机名与服务器 Certificate 消息中呈现的身份比较, 以防止中间人攻击.如果匹配失败, 客户端禁止尝试使用 SASL PLAIN 机制认证.规则与早期邮件相关规范一致: 使用打开连接时的主机名, 禁止使用不安全远程来源派生的主机名, 不做 CNAME 规范化; 若存在 dNSName subjectAltName 则应使用; 匹配不区分大小写; "*" 可作为最左名称组件; 多个名称中任一匹配即可.

B.5. XMPP (2004)

[XMPP-OLD] 在 2004 年规定, XMPP 对等体以安全方式通信时必须验证对端证书.证书可能属于三种情况: 终端实体证书可通过终止于信任锚的认证路径认证; 对端证书由验证方未知的 CA 认证; 或证书为自签名.

在第一种情况下, 验证方必须在两种方式中选择一种: 按 [PKIX] 规则验证对端证书, 并按 [HTTP-TLS] 规则检查证书是否匹配预期身份, 但如果存在 "xmpp" 类型 subjectAltName, 必须将其用作身份; 或向用户展示证书和完整认证路径以供批准, 并缓存证书或不可伪造表示, 未来连接中要求呈现同一证书.第二和第三种情况应按后一种方式处理.尽管 [XMPP-OLD] 定义了自己的规则, [XMPP] 后来复用了本文关于应用服务身份验证的规则.

B.6. NNTP (2006)

[NNTP-TLS] 在 2006 年规定, TLS 协商期间, 客户端必须把自己理解的服务器主机名与服务器 Certificate 消息中呈现的身份比较.客户端使用打开连接时的服务器主机名, 或 TLS "server_name" 扩展中指定的主机名, 禁止使用不安全远程来源派生出的任何主机名形式, 且不做 CNAME 规范化.若存在 dNSName subjectAltName, 应作为服务器身份来源.匹配不区分大小写, "*" 可作为最左名称组件, 多个名称中任一匹配即可.

如果匹配失败, 客户端应请求用户明确确认, 或使用 QUIT 命令终止连接并指出服务器身份可疑.此外, 客户端必须验证其连接服务器身份与服务器所呈现公钥之间的绑定.客户端应实现 [PKIX] 第 6 节中的通用证书验证算法, 也可以用达到等价验证级别的其他方法补充.

B.7. NETCONF (2006/2009)

[NETCONF-SSH] 在 2006 年规定, 在发送或接收基于密码的认证数据以及任何配置或状态数据之前, 客户端必须根据本地策略验证并认证服务器身份; 服务器也必须根据本地策略验证并认证客户端身份.任一方都不应与对端身份未知、意外或不正确的实体建立 NETCONF over SSH 连接.

[NETCONF-TLS] 在 2009 年规定, TLS 协商期间, 客户端必须仔细检查服务器呈现的证书是否符合预期, 特别是必须检查自己理解的服务器主机名与 Certificate 消息中呈现的服务器身份.规则沿用 [NNTP-TLS]: 使用打开连接时的主机名或 TLS "server_name" 扩展中的主机名; 禁止不安全派生名称和 CNAME 规范化; 如果存在 dNSName subjectAltName, 必须使用它; 匹配不区分大小写; "*" 可作为最左名称组件; 多个名称中任一匹配即可.匹配失败时, 客户端必须请求用户明确确认或终止连接.客户端还必须验证服务器身份与公钥之间的绑定.若客户端有外部信息可确定服务器预期身份, 可以省略主机名检查.

B.8. Syslog (2009)

[SYSLOG-TLS] 在 2009 年规定, 实现必须支持认证路径验证 [PKIX], 并必须支持使用本地配置的主机名指定授权对等体, 再按证书进行匹配.实现必须支持把本地配置主机名与 subjectAltName 扩展中的 dNSName 匹配, 并应支持与 subject distinguished name 的 common name 部分匹配.

"*" 通配符可用于 subjectAltName 的 dNSName 中, 也可用于承载主机名的 common name 中, 但只允许作为最左侧 DNS 标签.实现必须支持这种证书通配符, 也可以提供配置项禁用.本文还允许本地配置名称包含通配符以匹配一组值, 其灵活性可以高于 subject 名称中的通配符.若本地配置名称是国际化域名, 必须转换为 ACE 格式后比较.实现可以支持把本地配置 IP 地址与 subjectAltName 中的 iPAddress 匹配.

B.9. SIP (2010)

[SIP-CERTS] 在 2010 年规定, 实现比较两个 SIP 域身份时, 必须只比较每个 SIP 域标识符的 DNS 名称组件, 禁止在比较中使用任何 scheme 或参数.实现必须按 DNS 名称比较值, 即按 [DNS-CASE] 不区分大小写, 并必须按照 [PKIX] 第 7.2 节处理国际化域名.

实现必须完整匹配值, 禁止后缀匹配.例如 "foo.example.com" 不匹配 "example.com".实现还禁止匹配任何形式的通配符, 例如前导 "." 或 "." 与其他 DNS 标签或标签序列.因此, ".example.com" 只匹配字面值 "*.example.com", 不匹配 "foo.example.com".该规范通过此规则禁止 SIP 域证书中使用通配符.

B.10. SNMP (2010)

[SNMP-TLS] 在 2010 年规定, 如果服务器呈现的证书已通过针对配置信任锚的认证路径验证, 且存在 snmpTlstmAddrServerFingerprint 值为零长度的活动行, 则 snmpTlstmAddrServerIdentity 列包含预期主机名.该主机名随后与服务器证书比较.

实现必须支持把预期主机名与 subjectAltName 扩展中的 dNSName 匹配, 并可以支持检查 subject distinguished name 的 CommonName 部分."*" 通配符允许出现在 dNSName 中, 也可出现在用于存放主机名的 common name 中, 但只能作为最左 DNS 标签.实现必须支持这种通配符, 也可以提供配置项禁用.若本地配置名称是国际化域名, 必须转换为 ACE 格式后比较.若预期主机名不满足这些条件, 连接必须关闭.

B.11. GIST (2010)

[GIST] 在 2010 年规定了 General Internet Signalling Transport 中 TLS 的身份检查.TLS 认证后, 节点必须检查对端呈现的身份以避免中间人攻击, 并验证该对端被授权参与 GIST 层信令.授权检查通过把呈现身份依次与授权对等体数据库 (APD) 条目比较完成.

使用 X.509 证书进行 TLS 认证时, 必须把 DNS 命名空间中的身份与证书中每个 dNSName 类型 subjectAltName 扩展比较.如果没有此类扩展, 则必须与证书 Subject 字段中的最具体 Common Name 比较.DNS 名称匹配不区分大小写."*" 通配符可作为证书或 APD 身份中的最左名称组件.节点还必须验证其连接对端身份与对端呈现公钥之间的绑定, 并应实现 [PKIX] 第 6 节中的通用证书验证算法, 或用等价级别的其他验证方法补充.使用预共享密钥进行 TLS 认证时, psk_identity_hint 或 psk_identity 中的身份必须与 APD 中的身份比较.