跳到主要内容

RFC 4513 - LDAP: 认证方法与安全机制 (Authentication Methods and Security Mechanisms)

Network Working Group R. Harrison, Ed. Request for Comments: 4513 Novell, Inc. Obsoletes: 2251, 2829, 2830 June 2006 Category: Standards Track

本备忘录状态 (Status of This Memo)​

本文档为互联网社区规定了一项互联网标准跟踪协议, 并请求讨论与改进建议. 请参阅 "Internet Official Protocol Standards" (STD 1) 的当前版本, 以了解本协议的标准化状态. 本备忘录的分发不受限制.

Copyright (C) The Internet Society (2006).

摘要 (Abstract)​

本文档描述轻量级目录访问协议 (Lightweight Directory Access Protocol, LDAP) 的认证方法与安全机制. 文档详细说明如何使用 StartTLS 操作建立传输层安全 (Transport Layer Security, TLS).

本文档详细说明简单 Bind 认证方法, 包括匿名 (anonymous)、未认证 (unauthenticated) 以及名称/密码 (name/password) 机制; 以及简单认证与安全层 (Simple Authentication and Security Layer, SASL) Bind 认证方法, 包括 EXTERNAL 机制.

本文档讨论 LDAP 服务器会话可能经历的各种认证与授权状态, 以及触发这些状态变化的动作.

本文档与 LDAP 技术规范中的其他文档 (见规范路线图第 1 节) 一起, 废止 RFC 2251、RFC 2829 与 RFC 2830.

目录 (Table of Contents)​

  1. 引言
  2. 实现要求
  3. StartTLS 操作
  4. 授权状态
  5. Bind 操作
  6. 安全考虑
  7. IANA 考虑
  8. 致谢
  9. 规范性引用
  10. 资料性引用 附录 A. 认证与授权概念 附录 B. 变更摘要

1. 引言 (Introduction)​

轻量级目录访问协议 (LDAP) [RFC4510] 是访问目录的强大协议. 它提供搜索、检索与操纵目录内容的手段, 并提供访问丰富安全功能的方式.

这些安全功能必须在互联网上所有 LDAP 客户端与服务器之间可互操作; 因此, 凡声明符合 LDAP 的实现, 必须具备一组共同的最低安全功能子集.

LDAP 目录服务面临的基本威胁包括 (但不限于):

  1. 未授权访问目录数据 — 通过数据检索操作.
  2. 通过监视他人访问 — 未授权获取目录数据.
  3. 通过监视他人访问 — 未授权获取可重用的客户端认证信息.
  4. 未授权修改目录数据.
  5. 未授权修改配置信息.
  6. 拒绝服务 (DoS) — 以超额占用等方式使用资源, 意图拒绝他人服务.
  7. 欺骗 (Spoofing) — 诱使用户或客户端相信信息来自目录, 而实际并非如此 (通过修改传输中的数据或误导客户端传输连接); 诱使用户或客户端将特权信息发送给伪装成目录服务器的敌对实体; 诱使目录服务器相信信息来自特定客户端, 而实际来自敌对实体.
  8. 劫持 (Hijacking) — 攻击者夺取已建立协议会话的控制权.

威胁 (1)、(4)、(5)、(6)、(7) 与 (8) 属于主动攻击. 威胁 (2) 与 (3) 属于被动攻击. 威胁 (1)、(4)、(5) 与 (6) 来自敌对客户端; 威胁 (2)、(3)、(7) 与 (8) 来自客户端与服务器路径上的敌对代理, 或伪装成服务器的敌对代理 (例如 IP 欺骗).

LDAP 提供下列安全机制:

  1. 通过 Bind 操作进行认证. Bind 操作提供简单方法, 支持匿名、未认证与名称/密码机制; 以及 SASL 方法, 支持多种认证机制.
  2. 支持厂商特定访问控制设施的机制 (LDAP 本身不提供标准访问控制设施).
  3. 数据完整性服务 — 通过 TLS 或 SASL 机制中的安全层.
  4. 数据机密性服务 — 通过 TLS 或 SASL 机制中的安全层.
  5. 服务器资源使用限制 — 通过服务器上配置的管理限制.
  6. 服务器认证 — 通过 TLS 协议或 SASL 机制.

LDAP 也可由协议外的手段保护, 例如 IP 层安全 [RFC4301].

经验表明, 仅允许实现随意挑选要实现的安全机制, 并不能导向互操作性. 在缺少强制要求时, 客户端可能继续不支持服务器支持的任何安全功能, 或更糟, 只支持在多数情况下提供不足安全的机制.

期望允许客户端使用多种机制认证, 包括身份表示为可分辨名称 (distinguished name) [X.501][RFC4512]、字符串形式 [RFC4514], 或不同系统中使用的身份 (例如简单用户名 [RFC4013]). 由于某些认证机制以明文形式传输凭证, 和/或不提供数据安全服务, 和/或易受被动攻击, 有必要通过标识建立传输层安全服务的强制实现机制, 确保安全互操作.

本文档中描述的 LDAP 安全机制集合, 旨在满足广泛部署场景的安全需求, 同时在不同 LDAP 实现与部署之间保持高度互操作性.

1.1 与其他文档的关系 (Relationship to Other Documents)​

本文档是 LDAP 技术规范 [RFC4510] 的组成部分.

本文档与 [RFC4510]、[RFC4511] 与 [RFC4512] 一起, 完整废止 RFC 2251. RFC 2251 的第 4.2.1 节 (部分) 与第 4.2.2 节由本文档废止. 附录 B.1 总结了本文档对 RFC 2251 的实质性变更.

本文档完整废止 RFC 2829. 附录 B.2 总结了实质性变更.

RFC 2830 的第 2 节与第 4 节由 [RFC4511] 废止; 其余部分由本文档废止. 附录 B.3 总结了实质性变更.

1.2 约定 (Conventions)​

关键词 "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", "MAY" 与 "OPTIONAL" 的解释见 RFC 2119 [RFC2119].

术语 "user" (用户) 表示使用目录客户端访问目录的任何人类或应用实体. 目录客户端 (client) 亦称目录用户代理 (Directory User Agent, DUA).

术语 "transport connection" (传输连接) 指用于承载协议交换的底层传输服务, 以及这些服务建立的关联.

术语 "TLS layer" (TLS 层) 指用于提供安全服务的 TLS 服务, 以及这些服务建立的关联.

术语 "SASL layer" (SASL 层) 指用于提供安全服务的 SASL 服务, 以及这些服务建立的关联.

术语 "LDAP message layer" (LDAP 消息层) 指用于提供目录服务的 LDAP Message (PDU) 服务, 以及这些服务建立的关联.

术语 "LDAP session" (LDAP 会话) 指组合服务 (传输连接、TLS 层、SASL 层、LDAP 消息层) 及其关联.

总体而言, 本文档中的安全术语与 [RFC2828] 中的定义一致. 此外, 附录 A 给出若干与安全、认证与授权相关的术语与概念. 对这些术语与概念的正式定义超出本文档范围, 但理解它们是理解本文档大部分内容的前提. 不熟悉安全相关概念的读者在阅读其余部分前, 鼓励先阅读附录 A.

2. 实现要求 (Implementation Requirements)​

LDAP 服务器实现 MUST 支持简单 Bind 方法的匿名认证机制 (第 5.1.1 节).

支持除简单 Bind 匿名认证机制以外的任何认证机制的 LDAP 实现, MUST 支持简单 Bind 方法的名称/密码认证机制 (第 5.1.3 节), 并且 MUST 能够使用由 StartTLS 操作 (第 3 节) 建立的 TLS 保护该名称/密码认证.

实现 SHOULD 在默认情况下, 当合适的数据安全服务未就绪时, 禁止使用名称/密码认证机制; 实现 MAY 为该认证机制提供其他合适的数据安全服务.

实现 MAY 支持额外的认证机制. 下文讨论其中一部分.

LDAP 服务器实现 SHOULD 支持客户端通过 SASL EXTERNAL 机制 (第 5.2.3 节) 声明授权身份.

除简单 Bind 匿名机制外不支持任何其他认证机制的 LDAP 服务器实现, SHOULD 支持由 StartTLS 操作 (第 3 节) 建立的 TLS 使用. (其他服务器按本节第二段 MUST 支持 TLS.)

支持 TLS 的实现 MUST 支持 TLS_RSA_WITH_3DES_EDE_CBC_SHA 密码套件, 并 SHOULD 支持 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 密码套件. 推荐支持后者, 以促进与符合早期 LDAP StartTLS 规范的实现互操作.

3. StartTLS 操作 (StartTLS Operation)​

[RFC4511] 第 4.14 节定义的 Start Transport Layer Security (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 resultCode.

客户端实现者应严格遵循这些操作定序要求, 以避免互操作问题. 运维经验表明, 违反这些要求会导致互操作问题, 因为存在竞态条件, 使服务器由于服务器硬件速度与网络延迟等因素, 无法检测到某些违反情况.

没有一般性要求规定客户端在发送 StartTLS 操作请求之前是否必须已执行 Bind 操作 (第 5 节); 但若客户端既打算执行 Bind 又打算执行 StartTLS, 则 SHOULD 先执行 StartTLS, 以便 Bind 请求与响应消息受到 StartTLS 建立的数据安全服务保护.

3.1.2 客户端证书 (Client Certificate)​

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

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

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

为防止中间人攻击, 客户端 MUST 验证服务器身份 (如服务器 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 名称比较规则, 但不允许通配符匹配. 虽然使用 CN 值是既有实践, 但已被弃用; 鼓励证书颁发机构改为提供 subjectAltName 值. 注意 TLS 实现可能按 X.500 或其他约定表示证书中的 DN. 例如, 某些 X.500 实现按从左到右 (最显著到最不显著) 的约定排列 DN 中的 RDN, 而非 LDAP 的从右到左约定.

若服务器身份检查失败, 面向用户的客户端 SHOULD 通知用户 (此时客户端可允许用户继续 LDAP 会话) 或关闭传输连接并指示服务器身份可疑. 自动化客户端 SHOULD 关闭传输连接, 然后返回或记录指示服务器身份可疑的错误, 或两者都做.

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

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

若参考身份是国际化域名, 符合的实现在与 dNSName 类型的 subjectAltName 值比较前, MUST 按 RFC 3490 [RFC3490] 第 4 节将其转换为 ASCII Compatible Encoding (ACE) 格式. 具体地, 符合的实现 MUST 按如下执行 RFC 3490 第 4 节规定的转换操作:

  • 在步骤 1 中, 域名 SHALL 被视为 "stored string";
  • 在步骤 3 中, 设置名为 "UseSTD3ASCIIRules" 的标志;
  • 在步骤 4 中, 对每个标签执行 "ToASCII" 操作; 且
  • 在步骤 5 中, 将所有标签分隔符改为 U+002E (full stop).

执行 "to-ASCII" 转换后, DNS 标签与名称 MUST 按 RFC 3490 第 3 节规定的规则进行相等比较.

* (ASCII 42) 通配符字符允许出现在 dNSName 类型的 subjectAltName 值中, 且仅允许作为该值中最左侧 (最不显著) 的 DNS 标签. 该通配符匹配服务器名称中任意最左侧 DNS 标签. 即, 主体 *.example.com 匹配服务器名称 a.example.com 与 b.example.com, 但不匹配 example.com 或 a.b.example.com.

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

当参考身份是 IP 地址时, 该身份 MUST 转换为 "network byte order" 八位组串表示 [RFC791][RFC2460]. 对于 IPv4 (RFC 791), 八位组串恰好包含四个八位组. 对于 IPv6 (RFC 2460), 八位组串恰好包含十六个八位组. 然后将该八位组串与 iPAddress 类型的 subjectAltName 值比较. 当参考身份八位组串与值八位组串完全相同匹配时发生匹配.

3.1.3.3 其他 subjectName 类型比较​

客户端实现 MAY 支持按其他文档所述与其他类型的 subjectAltName 值匹配.

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

在 LDAP 会话中建立 TLS 层后, 双方须各自独立根据本地策略与所达到的安全级别决定是否继续. 若任一方认为安全级别不足以继续, SHOULD 在 TLS (重新) 协商完成后立即移除 TLS 层 (见 [RFC4511] 第 4.14.3 节及下文第 3.2 节). 实现可随时重新评估安全级别, 一旦发现不足, 应移除 TLS 层.

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

在 LDAP 会话中建立 TLS 层后, 客户端 SHOULD 丢弃或刷新其在 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 速度不断提升、缩短成功实施此类攻击所需时间的情况下.
  • 客户端与服务器实现者应仔细权衡所保护密码或数据的价值与密码套件提供的机密性保护级别, 确保保护级别适当.
  • 密码套件对中间人攻击的脆弱性 (或缺乏脆弱性). 易受中间人攻击的密码套件 SHOULD NOT 用于保护密码或敏感数据, 除非网络配置使中间人攻击危险可忽略.
  • 在 TLS 协商 (初始或后续) 完成后, 双方协议对等体应独立验证协商密码套件提供的安全服务是否足以用于 LDAP 会话的预期用途. 若不足, 应关闭 TLS 层.

4. 授权状态 (Authorization State)​

每个 LDAP 会话都有关联的授权状态. 该状态由多种因素组成, 例如已建立何种 (若有) 认证状态、如何建立, 以及已就位何种安全服务. 某些因素可能由协议事件 (例如 Bind、StartTLS 或 TLS 关闭) 决定和/或影响, 某些因素可能由外部事件 (例如一天中的时间或服务器负载) 决定.

虽然将授权状态以简化术语看待常常方便 (如本技术规范中经常所做), 例如 "匿名状态", 但需注意 LDAP 实现中的授权系统通常涉及以复杂方式相互关联的许多因素.

LDAP 中的授权是本地事务. 做出授权决策的关键因素之一是授权身份. Bind 操作 (在 [RFC4511] 第 4.2 节定义, 下文第 5 节进一步讨论) 允许在客户端与服务器之间交换信息, 为 LDAP 会话建立授权身份. Bind 操作也可用于将 LDAP 会话移至匿名授权状态 (见第 5.1.1 节).

在 LDAP 会话初始建立时, 会话具有匿名授权身份. 这尤其意味着客户端无需在 LDAP 消息层的第一个 PDU 中发送 BindRequest. 客户端可在执行 Bind 操作之前发送任何操作请求, 服务器 MUST 将其视为在匿名 Bind 操作 (第 5.1.1 节) 之后执行.

收到 Bind 请求后, 服务器立即将会话移至匿名授权状态. 若 Bind 请求成功, 会话移至所请求的认证状态及其关联授权状态. 否则, 会话保持匿名状态.

需注意, LDAP 内部与外部的其他事件都可能导致认证与授权状态移至匿名状态. 例如, 数据安全服务的建立、变更或关闭可能导致移至匿名状态, 或者用户的凭证信息 (例如证书) 可能已过期. 前者是 LDAP 内部事件的例子, 后者是 LDAP 外部事件的例子.

5. Bind 操作 (Bind Operation)​

Bind 操作 ([RFC4511], 第 4.2 节) 允许在客户端与服务器之间交换认证信息, 以建立新的授权状态.

Bind 请求通常指定期望的认证身份. 某些 Bind 机制还允许客户端指定授权身份. 若未指定授权身份, 服务器以实现特定的方式从认证身份导出授权身份.

若指定了授权身份, 服务器 MUST 验证客户端的认证身份是否被允许承担 (例如代理) 所声明的授权身份. 若客户端未被如此授权, 服务器 MUST 在 Bind 响应中以 invalidCredentials resultCode 拒绝 Bind 操作.

5.1 简单认证方法 (Simple Authentication Method)​

Bind 操作的简单认证方法提供三种认证机制:

  • 匿名认证机制 (第 5.1.1 节).
  • 未认证认证机制 (第 5.1.2 节).
  • 使用由名称 (LDAP 可分辨名称形式 [RFC4514]) 与密码组成的凭证的名称/密码认证机制 (第 5.1.3 节).

5.1.1 简单 Bind 的匿名认证机制​

LDAP 客户端可使用简单 Bind 方法的匿名认证机制, 通过发送 name 值为零长度、并指定包含零长度 password 值的 simple 认证选择的 Bind 请求, 显式建立匿名授权状态.

5.1.2 简单 Bind 的未认证认证机制​

LDAP 客户端可使用简单 Bind 方法的未认证认证机制, 通过发送 name 值 (非零长度的 LDAP 字符串形式可分辨名称 [RFC4514])、并指定包含零长度 password 值的 simple 认证选择的 Bind 请求, 建立匿名授权状态.

客户端提供的可分辨名称值意图仅用于跟踪 (例如日志) 目的. 该值不得被认证或以其他方式验证 (包括验证 DN 是否引用现有目录对象). 该值不得 (直接或间接) 用于授权目的.

未认证 Bind 操作可能有显著安全问题 (见第 6.3.1 节). 特别是, 意图执行名称/密码认证的用户可能无意中提供空密码, 从而导致实现不良的客户端请求未认证访问. 客户端 SHOULD 实现为要求用户通过输入空密码以外的方式选择未认证认证机制. 客户端 SHOULD 禁止在名称/密码认证用户界面中输入空密码. 此外, 服务器 SHOULD 默认以 unwillingToPerform resultCode 使未认证 Bind 请求失败.

5.1.3 简单 Bind 的名称/密码认证机制​

LDAP 客户端可使用简单 Bind 方法的名称/密码认证机制, 通过发送 name 值 (非零长度的 LDAP 字符串形式可分辨名称 [RFC4514])、并指定包含非零长度 OCTET STRING password 值的 simple 认证选择的 Bind 请求, 建立已认证的授权状态.

将 Bind 请求中发送的 DN 映射到具有与该机制一起使用的一组或多组关联密码的目录项的服务器, 会将出示的密码与该组密码比较. 若出示的密码匹配该组中的任一成员, 则视为有效.

invalidDNSyntax resultCode 指示 name 值中发送的 DN 在语法上无效. invalidCredentials resultCode 指示 DN 在语法上正确但对认证目的无效、密码对该 DN 无效, 或服务器以其他方式认为凭证无效. success resultCode 指示凭证有效, 且服务器愿意向这些凭证标识的实体提供服务.

对于指定名称/密码认证机制、name 值为零长度且 password 值为非零长度的 Bind 请求, 服务器行为未定义.

简单 Bind 方法的名称/密码认证机制不适合在没有机密性保护的环境中使用.

5.2 SASL 认证方法 (SASL Authentication Method)​

Bind 操作的 sasl 认证方法提供使用任何 SASL 机制的设施, 包括认证机制与其他服务 (例如数据安全服务).

5.2.1 SASL 协议配置文件 (SASL Protocol Profile)​

LDAP 允许通过任何 SASL 机制 [RFC4422] 进行认证. 由于 LDAP 包含原生匿名与名称/密码 (明文) 认证方法, ANONYMOUS [RFC4505] 与 PLAIN [PLAIN] SASL 机制通常不与 LDAP 一起使用.

每个利用 SASL 服务的协议都需要提供某些信息, 以描述这些服务如何通过该协议暴露 ([RFC4422], 第 4 节). 本节说明 LDAP 如何满足这些配置要求中的每一项.

5.2.1.1 LDAP 的 SASL 服务名称​

LDAP 的 SASL 服务名称为 "ldap", 已作为 SASL 服务名称向 IANA 注册.

5.2.1.2 SASL 认证启动与协议交换​

SASL 认证通过具有下列参数的 BindRequest 消息 ([RFC4511], 第 4.2 节) 启动:

  • version 为 3.
  • AuthenticationChoice 为 sasl.
  • SaslCredentials 序列的 mechanism 元素包含期望的 SASL 机制值.
  • SaslCredentials 序列的可选 credentials 字段 MAY 用于为定义为客户端先发送数据的机制提供初始客户端响应 (见 [RFC4422] 第 3 节与第 5 节).

一般而言, SASL 认证协议交换由一系列服务器挑战与客户端响应组成, 其内容由 SASL 机制特定定义. 因此, 对某些 SASL 认证机制, 客户端可能需要通过多次发送 BindRequest 消息来响应一个或多个服务器挑战. 挑战由服务器发送 resultCode 设置为 saslBindInProgress 的 BindResponse 消息指示. 这表示服务器要求客户端发送具有相同 SASL 机制的新 BindRequest 消息以继续认证过程.

对 LDAP 消息层而言, 这些挑战与响应是任意长度的不透明二进制令牌. LDAP 服务器使用 BindResponse 消息中的 serverSaslCreds 字段 (OCTET STRING) 传输每个挑战. LDAP 客户端使用 BindRequest 消息 SaslCredentials 序列中的 credentials 字段 (OCTET STRING) 传输每个响应. 注意, 与某些使用 SASL 的互联网协议不同, LDAP 不是基于文本的, 且不对这些挑战与响应值做 Base64 变换.

选择 sasl 的客户端发送 BindRequest 消息时 SHOULD 在 name 字段中发送零长度值. 收到选择 sasl 的 BindRequest 消息的服务器 SHALL 忽略 name 字段中的任何值.

客户端可通过发送 SaslCredentials 的 mechanism 字段为不同值的 BindRequest 消息, 或 AuthenticationChoice 非 sasl 的 BindRequest 消息, 中止 SASL Bind 协商.

若客户端发送 sasl mechanism 字段为空字符串的 BindRequest, 服务器 MUST 返回 resultCode 为 authMethodNotSupported 的 BindResponse. 这允许客户端在希望以相同 SASL 机制重试时中止协商.

服务器通过响应 resultCode 值不是 saslBindInProgress 的 BindResponse 指示 SASL 挑战-响应交换完成.

BindResponse 中的 serverSaslCreds 字段可用于对定义为服务器在成功完成指示的同时发送额外数据的机制, 在成功通知中包含可选挑战.

5.2.1.3 可选字段 (Optional Fields)​

如上所述, LDAP 在启动 SASL 交换的消息中提供可选字段以携带初始响应, 并在指示认证交换结果的消息中提供可选字段以携带额外数据. 由于这些字段中的机制特定内容可能为零长度, SASL 要求协议规范详细说明如何区分空字段与缺席字段.

零长度初始响应数据与启动消息 (BindRequest PDU) 中无初始响应数据的区分方式是: 该 PDU 中存在 (长度为 0 的) SaslCredentials.credentials OCTET STRING. 若客户端不打算在启动 SASL 交换的 BindRequest 中发送初始响应, MUST 省略 SaslCredentials.credentials OCTET STRING (而非包含零长度 OCTET STRING).

零长度额外数据与结果消息 (BindResponse PDU) 中无额外响应数据的区分方式是: 该 PDU 中存在 (长度为 0 的) serverSaslCreds OCTET STRING. 若服务器不打算在指示交换结果的 BindResponse 消息中发送额外数据, 服务器 SHALL 省略 serverSaslCreds OCTET STRING (而非包含零长度 OCTET STRING).

5.2.1.4 协商安全层生效的八位组​

SASL 层在服务器传输、客户端接收 SASL 交换中 resultCode 为 success 的最终 BindResponse 之后生效.

一旦提供数据完整性或机密性服务的 SASL 层生效, 该层保持有效, 直到安装新层 (即在导致新层生效的 Bind 操作的最终 BindResponse 之后的第一个八位组). 因此, 已建立的 SASL 层不受失败或非 SASL Bind 影响.

5.2.1.5 支持的 SASL 机制的确定​

客户端可通过从根 DSE (DSA-Specific Entry) ([RFC4512], 第 5.1 节) 读取 supportedSASLMechanisms 属性, 确定服务器支持的 SASL 机制. 该属性的值 (若有) 列出服务器在当前 LDAP 会话状态下支持的机制. LDAP 服务器 SHOULD 允许所有客户端 — 即使具有匿名授权的客户端 — 在 SASL 认证交换之前与之后检索根 DSE 的 supportedSASLMechanisms 属性. 后者的目的是允许客户端检测可能的降级攻击 (见第 6.4 节与 [RFC4422] 第 6.1.2 节).

由于 SASL 机制提供关键安全功能, 客户端与服务器应可配置为指定哪些机制可接受, 并仅允许使用这些机制. 客户端与服务器在继续使用会话前都必须确认协商的安全级别满足其要求.

5.2.1.6 使用 SASL 层的规则​

安装 SASL 层后, 客户端 SHOULD 丢弃或刷新其在 SASL 协商启动之前获得的、且非通过安全机制获得的所有关于服务器的信息.

若安装了较低层安全层 (例如 TLS), 任何 SASL 层 SHALL 叠加在这些安全层之上, 无论其协商顺序如何. 在所有其他方面, SASL 层与其他安全层独立作用; 例如, 若 TLS 层与 SASL 层同时有效, 则移除 TLS 层不影响 SASL 层的持续服务.

5.2.1.7 对多次认证的支持​

LDAP 支持 [RFC4422] 第 4 节定义的多次 SASL 认证.

5.2.1.8 SASL 授权身份 (SASL Authorization Identities)​

某些 SASL 机制允许客户端为 LDAP 会话请求期望的授权身份 ([RFC4422], 第 3.4 节). 是否允许当前认证身份访问所请求的授权身份, 是本地策略事务. 授权身份是与下列增广巴科斯-瑙尔范式 (ABNF) [RFC4234] 语法对应的 UTF-8 [RFC3629] 编码 [Unicode] 字符串:

authzId = dnAuthzId / uAuthzId

; distinguished-name-based authz id
dnAuthzId =  "dn:" distinguishedName

; unspecified authorization id, UTF-8 encoded
uAuthzId = "u:" userid
userid = *UTF8 ; syntax unspecified

其中 distinguishedName 规则在 [RFC4514] 第 3 节定义, UTF8 规则在 [RFC4512] 第 1.4 节定义.

dnAuthzId 选择用于以可分辨名称形式声明授权身份, 按 distinguishedNameMatch 匹配规则 ([RFC4517], 第 4.2.15 节) 匹配. 不要求所声明的 distinguishedName 值是目录中某项的 DN.

uAuthzId 选择允许客户端声明非可分辨名称形式的授权身份. userid 的格式仅定义为 UTF-8 [RFC3629] 编码 [Unicode] 字符序列, 任何进一步解释是本地事务. 例如, userid 可标识特定目录服务的用户、登录名或电子邮件地址. SHOULD NOT 假定 uAuthzId 全局唯一. 要比较 uAuthzId 值, 每个 uAuthzId 值 MUST 使用 SASLprep [RFC4013] 算法作为 "query" 字符串 ([RFC3454], 第 7 节) 准备, 然后按八位组比较两个值.

上述语法可扩展. authzId 产生式可扩展以支持额外的身份形式. 每种形式由其唯一前缀区分 (注册要求见 [RFC4520] 第 3.12 节).

5.2.2 LDAP 内的 SASL 语义 (SASL Semantics within LDAP)​

实现者在处理在 LDAP 协议中具有不同语义的数据时, 必须注意维护 SASL 规范的语义.

例如, SASL DIGEST-MD5 认证机制 [DIGEST-MD5] 使用语法上为简单字符串、语义上为简单用户名 [RFC4013] 与领域值的认证身份与领域. 这些值不是 LDAP DN, 且没有要求将它们表示为或当作 LDAP DN.

5.2.3 SASL EXTERNAL 认证机制​

客户端可使用 SASL EXTERNAL ([RFC4422], 附录 A) 机制, 请求 LDAP 服务器使用较低安全层交换的安全凭证 (例如通过 TLS 认证) 进行认证并建立结果授权身份. 若客户端的认证凭证尚未在较低安全层建立, SASL EXTERNAL Bind MUST 以 inappropriateAuthentication resultCode 失败. 虽然此情况会使 LDAP 会话处于匿名状态 (第 4 节), 但任何已安装安全层的状态不受影响.

客户端可请求其授权身份从较低安全层交换的认证凭证自动导出, 也可显式提供期望的授权身份. 前者称为隐式声明, 后者称为显式声明.

5.2.3.1 隐式声明 (Implicit Assertion)​

隐式授权身份声明通过调用使用 EXTERNAL 机制名、且不包含可选 credentials 字段 (位于 BindRequest 中 SaslCredentials 序列内) 的 SASL 形式 Bind 请求执行. 服务器将根据本地策略, 从安全层提供的认证身份 (例如 TLS 层安装期间使用的公钥证书) 导出客户端的授权身份. 如何完成的底层机制是实现特定的.

5.2.3.2 显式声明 (Explicit Assertion)​

显式授权身份声明通过调用使用 EXTERNAL 机制名、且包含 credentials 字段 (位于 BindRequest 中 SaslCredentials 序列内) 的 SASL 形式 Bind 请求执行. credentials 字段的值 (OCTET STRING) 是所声明的授权身份, MUST 按第 5.2.1.8 节所述构造.

6. 安全考虑 (Security Considerations)​

本文档通篇讨论安全问题. 不出所料的结论是: 安全是 LDAP 不可或缺且必要的部分. 本节讨论若干与 LDAP 相关的安全考虑.

6.1 一般 LDAP 安全考虑​

LDAP 本身不提供对通过 LDAP 协议以外手段访问或更新目录的安全或保护, 例如数据库管理员检查服务器数据库文件.

敏感数据几乎可在任何 LDAP 消息中携带, 其披露在许多国家可能受隐私法或其他法律监管. 实现者应采取适当措施保护敏感数据, 防止向未授权实体披露.

客户端尚未建立数据完整性与隐私服务 (例如通过 StartTLS、IPsec 或合适的 SASL 机制) 的会话, 易受中间人攻击以查看与修改传输中的信息. 客户端与服务器实现者 SHOULD 采取本文档讨论的数据保护服务措施, 保护 LDAP 会话中的敏感数据免受这些攻击. 客户端与服务器应提供可配置为要求这些保护的能力. confidentialityRequired resultCode 指示服务器要求建立 (更强的) 数据机密性保护才能执行所请求的操作.

读取敏感信息或更新目录信息时始终应应用访问控制.

各种安全因素, 包括认证与授权信息以及数据安全服务, 可能在 LDAP 会话过程中甚至在执行特定操作期间发生变化. 实现在处理变化的安全因素时应健壮.

6.2 StartTLS 安全考虑​

通过使用 StartTLS 操作获得的所有安全, 都是通过使用 TLS 本身获得的. StartTLS 操作本身不提供任何额外安全.

通过使用 TLS 提供的安全级别直接取决于所用 TLS 实现的质量以及该实现的使用方式. 此外, 中间人攻击者可从根 DSE 的 supportedExtension 属性中移除 StartTLS 扩展操作. 双方 SHOULD 在 TLS 建立后、开始使用 TLS 保护会话前, 独立查明并同意所达到的安全级别. 例如, TLS 层的安全级别可能已被协商降为明文.

当所达到的安全级别不提供可接受的数据机密性和/或数据完整性保护级别时, 客户端 MUST 警告用户, 或可配置为在没有可接受安全级别时拒绝继续.

如第 3.1.2 节所述, 服务器可使用本地安全策略决定是否成功完成 TLS 协商. 策略管理员在配置识别与授权策略时, 应使用由证书颁发机构发起或验证的用户证书中的信息.

服务器实现者 SHOULD 允许服务器管理员选择是否以及何时要求数据机密性与完整性, 以及是否在 TLS 握手期间要求客户端认证.

实现者应知晓并理解 TLS 规范 [RFC4346] 中讨论的 TLS 安全考虑.

6.3 Bind 操作安全考虑​

本节讨论与通过 Bind 操作进行 LDAP 认证相关的若干安全考虑.

6.3.1 未认证机制安全考虑​

运维经验表明, 客户端可以 (且经常) 误用简单 Bind 方法的未认证认证机制 (见第 5.1.2 节). 例如, 客户端程序可能基于成功完成 Bind 操作而决定授予对非目录信息的访问权. LDAP 服务器实现可能对未认证 Bind 请求返回 success 响应. 这可能错误地使客户端以为服务器已成功认证由可分辨名称表示的身份, 而实际上建立的是匿名授权状态. 使用简单 Bind 操作结果做出授权决策的客户端应主动检测未认证 Bind 请求 (通过验证所提供密码非空) 并做出适当反应.

6.3.2 名称/密码机制安全考虑​

简单 Bind 方法的名称/密码认证机制向服务器披露密码, 这是固有安全风险. 存在其他机制, 例如 SASL DIGEST-MD5 [DIGEST-MD5], 不会向服务器披露密码.

6.3.3 与密码相关的安全考虑​

LDAP 允许多值密码属性. 在期望项有且仅有一个密码的系统中, 应提供管理控制以强制该行为.

当底层传输服务不能保证机密性时, 强烈不鼓励在开放网络上使用明文密码与其他未受保护的认证凭证. 除非会话上的数据使用 TLS 或其他数据机密性与数据完整性保护进行保护, LDAP 实现 SHOULD NOT 默认支持使用明文密码与其他未受保护认证凭证的认证方法.

以明文传输密码 — 通常用于认证或修改 — 构成显著安全风险. 可通过使用不在明文中传输密码的 SASL 认证 [RFC4422] 机制, 或在传输密码值之前协商传输层或会话层数据机密性服务, 避免该风险.

为减轻与密码传输相关的安全风险, 支持任何以明文传输密码的基于密码的认证机制的服务器实现, MUST 支持在认证或密码修改时要求下列之一的策略机制:

  • 已成功安装 TLS 层; 或者
  • 已提供保护密码值免受窃听的其他数据机密性机制; 或者
  • 服务器对该操作返回 confidentialityRequired resultCode (即带密码值的名称/密码 Bind、以明文传输密码值的 SASL Bind、包含 userPassword 值的 add 或 modify 等), 即使密码值正确.

服务器实现可能还希望在服务器检测到某账户密码以明文传输时, 提供使账户失效或以其他方式保护账户的策略机制.

6.3.4 哈希密码安全考虑​

某些认证机制 (例如 DIGEST-MD5) 传输可能易受离线字典攻击的密码值哈希. 实现者应注意在传输期间使用 TLS 或其他机密性机制保护此类哈希密码值.

6.4 SASL 安全考虑​

在 LDAP 会话上安装数据完整性服务之前, 攻击者可修改 supportedSASLMechanisms 属性响应的传输值, 从而将可用 SASL 机制列表降级为仅包含最不安全的机制. 为检测此类攻击, 客户端可在 LDAP 会话上安装数据完整性服务之前与之后检索服务器提供的 SASL 机制. 若客户端发现完整性保护列表 (在安装数据完整性服务后获得的列表) 包含比先前获得列表中更强的机制, 客户端应假定先前获得的列表已被攻击者修改. 在此情况下, 建议客户端关闭底层传输连接, 然后重新连接以重新建立会话.

6.5 相关安全考虑​

与本文档讨论的各种认证方法与机制相关的额外安全考虑适用, 见 [RFC4422]、[RFC4013]、[RFC3454] 与 [RFC3629].

7. IANA 考虑 (IANA Considerations)​

IANA 已更新 LDAP Protocol Mechanism 注册表, 以指示本文档与 [RFC4511] 提供 StartTLS (1.3.6.1.4.1.1466.20037) 扩展操作的权威技术规范.

IANA 已更新 LDAP LDAPMessage types 注册表, 以指示本文档与 [RFC4511] 提供 bindRequest (0) 与 bindResponse (1) 消息类型的权威技术规范.

IANA 已更新 LDAP Bind Authentication Method 注册表, 以指示本文档与 [RFC4511] 提供 simple (0) 与 sasl (3) bind 认证方法的权威技术规范.

IANA 已更新 LDAP authzid prefixes 注册表, 以指示本文档提供 dnAuthzId (dn:) 与 uAuthzId (u:) authzid 前缀的权威技术规范.

8. 致谢 (Acknowledgements)​

本文档合并了原先包含在 RFC 2251、RFC 2829 与 RFC 2830 中的信息. RFC 2251 是 Access, Searching, and Indexing of Directories (ASID) 工作组的产物. RFC 2829 与 RFC 2830 是 LDAP Extensions (LDAPEXT) 工作组的产物.

本文档是 IETF LDAP Revision (LDAPBIS) 工作组的产物.

9. 规范性引用 (Normative References)​

  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  • [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
  • [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, March 2006.
  • [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
  • [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
  • [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
  • [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
  • [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
  • [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
  • [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
  • [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0".
  • [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.

10. 资料性引用 (Informative References)​

  • [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest Authentication as a SASL Mechanism", Work in Progress, March 2006.
  • [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in Progress, March 2005.
  • [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505, June 2006.

附录 A. 认证与授权概念 (Authentication and Authorization Concepts)​

本附录为非规范性.

本附录定义关于认证、授权、凭证与身份的基本术语、概念与相互关系. 这些概念用于描述各种安全方法如何用于客户端认证与授权.

A.1 访问控制策略 (Access Control Policy)​

访问控制策略是一组规则, 定义对资源的保护, 通常以访问这些资源的人员或其他实体的能力来表述. 安全对象与机制 (例如本文所述) 使访问控制策略的表达与强制成为可能.

A.2 访问控制因素 (Access Control Factors)​

当服务器处理请求时, 请求可能与多种安全相关因素关联. 服务器使用这些因素决定是否以及如何处理请求. 这些称为访问控制因素 (Access Control Factors, ACFs). 它们可能包括源 IP 地址、加密强度、所请求操作的类型、一天中的时间等. 某些因素可能特定于请求本身; 其他可能与传输请求的传输连接关联; 还有其他 (例如一天中的时间) 可能是 "环境" 性的.

访问控制策略以访问控制因素表述; 例如, "具有 ACF i,j,k 的请求可对资源 Z 执行操作 Y". 服务器为此类表达提供的 ACF 集合是实现特定的.

A.3 认证、凭证、身份 (Authentication, Credentials, Identity)​

认证凭证是一方提供给另一方的证据, 声明提供方 (例如用户) 的身份, 该提供方试图与另一方 (通常是服务器) 建立新的授权状态. 认证是生成、传输与验证这些凭证以及它们所声明身份的过程. 认证身份是凭证中呈现的名称.

认证凭证有多种形式. 所用形式取决于各方协商的特定认证机制. X.509 证书、Kerberos 票据以及简单身份与密码对都是认证凭证形式的例子. 注意, 认证机制可能约束与之使用的认证身份形式.

A.4 授权身份 (Authorization Identity)​

授权身份是一种访问控制因素. 它是请求执行操作的用户或其他实体的名称. 访问控制策略常常以授权身份表述; 例如, "实体 X 可对资源 Z 执行操作 Y".

LDAP 会话的授权身份在语义上常常与客户端呈现的认证身份相同, 但也可能不同. SASL 允许客户端指定与客户端凭证声明的认证身份不同的授权身份. 这允许代理服务器等代理使用自己的凭证认证, 却请求所代理身份的访问特权 [RFC4422]. 此外, TLS 等服务提供的认证身份形式可能与用于表达服务器访问控制策略的授权身份不对应, 因此需要做服务器特定的映射. 服务器如何从客户端提供的认证凭证组合并验证授权身份的方法是实现特定的.

附录 B. 变更摘要 (Summary of Changes)​

本附录为非规范性.

本附录总结对 RFC 2251、RFC 2829 与 RFC 2830 所做的实质性变更. 除下文详述的具体变更外, 读者应注意对源文档原始内容做了大量一般性编辑变更, 包括:

  • 将原先在 RFC 2251 第 4.2.1 与 4.2.2 节、RFC 2829 (除第 2 与 4 节外的所有节) 以及 RFC 2830 中的材料合并为单一文档.
  • 对合并材料进行实质性重组与编辑, 以对相关主题分组、改善文档流程并澄清意图.
  • 全文变更以与 LDAP 协议层定义及 IETF 安全术语对齐.
  • 基于当前运维经验, 对两份文档的安全考虑进行了实质性更新与补充.

B.1 对 RFC 2251 的变更​

  • 澄清 Bind 请求定序与中止行为.
  • 重组认证与其他安全服务的描述, 并与 StartTLS / SASL 模型对齐.

B.2 对 RFC 2829 的变更​

  • 更新强制/推荐安全机制要求.
  • 澄清匿名、基于密码与基于证书的规程.
  • 将实现要求与 TLS 密码套件建议更新为本文档第 2 节与第 3.3 节所述.
  • 将授权身份语法统一到第 5.2.1.8 节.

B.3 对 RFC 2830 的变更​

  • 加强并详述服务器身份检查 (第 3.1.3 节).
  • 要求在 TLS 建立后刷新服务器能力信息.
  • 澄清 TLS 对客户端授权身份与 TLS 连接关闭效果的影响.

相关资源​

说明: 英文源为完整 RFC 文本. 本中文版按章节完整翻译技术内容、规范要求与安全要点; 个别冗长编辑性变更列表与原始分页空白已压缩, 实现时请同时对照英文源与 [RFC4511]/[RFC4422] 相关条款.

最后于 更新