跳到主要内容

3. StartTLS 操作 (StartTLS Operation)

[RFC4511] 第 4.14 节定义的启动传输层安全 (StartTLS) 操作提供了在 LDAP 会话中建立 TLS [RFC4346] 的能力.

将 TLS 协议与 LDAP 配合使用的目标是确保数据的保密性与完整性, 并可选地提供认证. TLS 明确地提供了这些能力, 不过 TLS 的认证服务只有在与 SASL EXTERNAL 认证方法 (见第 5.2.3 节) 结合时才对 LDAP 可用, 并且即便如此, 也只有当 SASL EXTERNAL 的实现选择使用 TLS 凭证时才可用.

3.1 TLS 建立规程 (TLS Establishment Procedures)​

本节描述客户端和服务器在建立 TLS 时必须遵循的总体规程. 这些规程考虑了 TLS 层的多个方面, 包括最终安全级别的发现和客户端授权身份的断言.

3.1.1 StartTLS 请求排序 (StartTLS Request Sequencing)​

客户端可以在建立 LDAP 会话之后的任何时刻发送 StartTLS 扩展请求, 但以下情况除外:

  • 当前会话上已建立 TLS 时;

  • 会话上正在进行多阶段 SASL 协商时; 或者

  • 会话上先前发出的操作请求尚有待回复的响应时.

如 [RFC4511] 第 4.14.1 节所述, (检测到) 违反上述任何要求都会导致返回 operationsError 结果码.

客户端实现者应当确保严格遵循这些操作排序要求, 以防止互操作性问题. 运营经验表明, 违反这些要求会导致互操作性问题, 因为存在竞争条件, 使得服务器由于服务器硬件速度和网络延迟等因素而无法检测到对这些要求的某些违反.

没有一般性要求客户端在发送 StartTLS 操作请求之前已经执行或尚未执行 Bind 操作 (第 5 节); 但是, 如果客户端打算既执行 Bind 操作又执行 StartTLS 操作, 它应当先执行 StartTLS 操作, 使得 Bind 请求与响应消息受到 StartTLS 操作所建立的数据安全服务的保护.

3.1.2 客户端证书 (Client Certificate)​

如果 LDAP 服务器在 TLS 协商期间请求或要求客户端提供用户证书, 而客户端没有出示合适的用户证书 (例如一个可以被验证的证书), 服务器可以使用本地安全策略来决定是否成功完成 TLS 协商.

如果已提供了合适证书的客户端随后使用 SASL EXTERNAL 认证机制 (第 5.2.3 节) 执行 Bind 操作, 服务器可以使用证书中的信息来标识和认证该客户端.

3.1.3 服务器身份检查 (Server Identity Check)​

为了防止中间人攻击, 客户端必须验证服务器的身份 (如在服务器的 Certificate 消息中所呈现). 在本节中, 客户端对服务器身份的理解 (通常是用于建立传输连接的身份) 称为 "参考身份" (reference identity).

客户端确定参考身份的类型 (例如 DNS 名或 IP 地址), 并在参考身份与该类型的每个 subjectAltName 值之间进行比较, 直到产生一个匹配. 一旦产生匹配, 服务器的身份就已得到验证, 服务器身份检查即告完成. 不同类型的 subjectAltName 以不同方式匹配. 第 3.1.3.1 至 3.1.3.3 节解释如何比较各种 subjectAltName 类型的值.

客户端可以在执行比较之前把参考身份映射为另一种类型. 可以对参考身份能够映射到的所有可用 subjectAltName 类型执行映射; 但是, 参考身份只应映射到这样一些类型: 映射本身是固有安全的 (例如从 URI 中提取 DNS 名, 与类型为 dNSName 的 subjectAltName 比较), 或者映射是以安全方式执行的 (例如使用 DNSSEC, 或使用用户或管理员配置的主机到地址/地址到主机查找表).

服务器的身份也可以通过把参考身份与服务器证书的 subjectName 字段中叶相对可辨识名 (RDN) 的 Common Name (CN) [RFC4519] 值进行比较来验证. 该比较使用下文第 3.1.3.1 节中 DNS 名的比较规则, 但不允许通配符匹配. 尽管使用 Common Name 值是现有实践, 但它已被弃用, 鼓励认证机构改为提供 subjectAltName 值. 注意, TLS 实现可能按 X.500 或其他约定表示证书中的 DN. 例如, 一些 X.500 实现按从左到右 (最高有效到最低有效) 的约定排列 DN 中的 RDN, 而不是 LDAP 的从右到左约定.

如果服务器身份检查失败, 面向用户的客户端应当通知用户 (这种情况下客户端可以让用户有机会继续 LDAP 会话), 或者关闭传输连接并指出服务器身份可疑. 自动化客户端应当关闭传输连接, 然后返回或记录一条指出服务器身份可疑的错误, 或两者兼施.

除了本节描述的服务器身份检查之外, 客户端还应准备做进一步的检查, 以确保服务器有权提供它被请求提供的服务. 客户端在做出这一判定时可能需要利用本地策略信息.

3.1.3.1 DNS 名的比较 (Comparison of DNS Names)​

如果参考身份是一个国际化域名, 符合规范的实现必须先把它转换为 ASCII 兼容编码 (ACE) 格式 (按 RFC 3490 [RFC3490] 第 4 节的规定), 然后再与类型为 dNSName 的 subjectAltName 值比较. 具体而言, 符合规范的实现必须按如下方式执行 RFC 3490 第 4 节规定的转换操作:

  • 在步骤 1 中, 域名应被视为 "stored string" (存储字符串);

  • 在步骤 3 中, 设置名为 "UseSTD3ASCIIRules" 的标志;

  • 在步骤 4 中, 对每个标签执行 "ToASCII" 操作; 并且

  • 在步骤 5 中, 把所有标签分隔符改为 U+002E (句点).

执行 "to-ASCII" 转换之后, 必须按 RFC 3490 第 3 节规定的规则比较 DNS 标签和名称是否相等.

'*' (ASCII 42) 通配符字符允许出现在类型为 dNSName 的 subjectAltName 值中, 且只能作为该值中最左 (最低有效) 的 DNS 标签. 该通配符匹配服务器名中最左的任意 DNS 标签. 也就是说, subject *.example.com 匹配服务器名 a.example.com 和 b.example.com, 但不匹配 example.com 或 a.b.example.com.

3.1.3.2 IP 地址的比较 (Comparison of IP Addresses)​

当参考身份是 IP 地址时, 必须把该身份转换为 "网络字节序" 的八位组串表示 [RFC791][RFC2460]. 对于 RFC 791 规定的 IP 版本 4, 该八位组串恰好包含四个八位组. 对于 RFC 2460 规定的 IP 版本 6, 该八位组串恰好包含十六个八位组. 然后将该八位组串与类型为 iPAddress 的 subjectAltName 值比较. 如果参考身份八位组串与值八位组串完全相同, 则发生匹配.

3.1.3.3 其他 subjectName 类型的比较 (Comparison of Other subjectName Types)​

客户端实现可以按其他文档的描述, 支持对其他类型 subjectAltName 值的匹配.

3.1.4 最终安全级别的发现 (Discovery of Resultant Security Level)​

在 LDAP 会话中建立 TLS 层之后, 双方各自独立地基于本地策略和所达到的安全级别决定是否继续. 如果任何一方判定安全级别不足以让它继续, 它应当在 TLS (重新) 协商完成后立即移除 TLS 层 (见 [RFC4511] 第 4.14.3 节以及下文第 3.2 节). 实现可以在任何时候重新评估安全级别, 并在发现不充分时移除 TLS 层.

3.1.5 服务器能力信息的刷新 (Refresh of Server Capabilities Information)​

在 LDAP 会话中建立 TLS 层之后, 客户端应当丢弃或刷新它在发起 TLS 协商之前获得的, 且不是通过安全机制获得的关于该服务器的全部信息. 这可以防止可能已在 TLS 层安装之前篡改了所获取的任何服务器能力信息的中间人攻击.

服务器在安装 TLS 层之后可能通告不同的能力. 特别是, 'supportedSASLMechanisms' 的值在 TLS 层安装之后可能不同 (具体而言, EXTERNAL 和 PLAIN [PLAIN] 机制很可能只在 TLS 层安装之后才会列出).

3.2 TLS 对授权状态的影响 (Effect of TLS on Authorization State)​

TLS 的建立, 变更和/或关闭可能使授权状态迁移到一个新的状态. 这在第 4 节中进一步讨论.

3.3 TLS 密码套件 (TLS Ciphersuites)​

在选择适用于特定情形的 TLS 密码套件时, 应当考虑以下几个问题. 这些问题包括:

  • 该密码套件为口令和经传输连接发送的其他数据提供足够保密性保护的能力. 客户端和服务器实现者应当认识到, 一些 TLS 密码套件不提供保密性保护, 而提供保密性保护的其他密码套件也可能容易受到暴力破解方法的攻击, 考虑到不断提高的 CPU 速度缩短了成功发起此类攻击所需的时间, 这一点尤其突出.

  • 客户端和服务器实现者应当仔细权衡被保护口令或数据的价值与该密码套件所提供的保密性保护级别, 以确保该密码套件提供的保护级别是恰当的.

  • 该密码套件对中间人攻击的易感性 (或缺乏 thereof). 易受中间人攻击的密码套件不应用于保护口令或敏感数据, 除非网络配置使得中间人攻击的危险可以忽略不计.

  • 在一次 TLS 协商 (初始的或后续的) 完成之后, 协议双方都应当独立地验证所协商密码套件提供的安全服务对于 LDAP 会话的预期用途而言是否充分. 如果不充分, 则应关闭 TLS 层.