rfc2829.txt

很多RFC的中文文档

权（privileges）。另外，通过像TLS服务提供的认证身份标识的形式可以不相对于应用于明
确的服务存取控制协议的授权身份标识，需要服务特指映射（server-specific mapping）被
做。从客户提供的认证证明中通过服务组成和生效的授权身份标识的方法是工具相关的
（implementation-specific）。

4. 必须的安全机制
   	允许任何工具，面对上面的需求，在可以选择的（安全机制）中选择是不策略的
（strategy），很可能导致互操作性问题是很明显的。在缺少授权（mandates）的情况下，客
户（程序）将被记述（written）不支持任何服务（程序）支持的安全功能（function），或
者更坏，仅仅支持类似明文口令的机制其提供明显不够的（inadequate）安全。

   	主动中间攻击（Active intermediary attacks）对攻击者的（攻击）执行是很困难的，
同时采用工具防止危害也是很困难的。在基于认识到（perceived）主动中间攻击的危险下去
避免主动中间攻击的危害所付出的代价的情况下，采取方法（Methods）仅仅避免敌对客户
（hostile client）和被动监听攻击（passive eavesdropping attacks）所带来的危害是有
效的（useful）。

   	给定已存在的目录，强烈要求看到获得甄别名（Distinguished Name）的形式和能够存
储在目录中的认证数据的身份（标识）机制；这意味着或者这个数据为了虚假的认证是无用
的（就像过去Unix使用的"/etc/passwd"文件格式），或者它的内容从来没有通过无保护的线
路中——也就是说它或者更新（updated）协议的外面（outside）或者仅在会话中更新以很
好地避免了窥探者的危害。它也希望允许认证方法基于存在的用户身份（标识）形式携带授
权身份标识，目的为了与non-LDAP-based 认证服务向后兼容（backwards compatibility）。

   	因此，下列工具的一致性需求（conformance requirements）如下：

      (1)   对于只读、公开目录、匿名认证在部分5中描述，能被使用。

      (2)   工具提供基于口令（password-based）的认证访问必须（MUST）支持使用
DIGEST-MD5 SASL 机制[4]的认证，在部分6.1中描述。这提供了客户避免被动
监听攻击（passive eavesdropping attacks）的认证，但是没有提供避免主动
中间攻击。

      (3)   对于需要会话保护和认证的目录，启动TLS扩展操作[5]，和或者简单认证选择
或者SASL EXTERNAL 机制，被一起使用。工具应该（SHOULD）支持在部分6.2
中描述的口令认证，和应该（SHOULD）支持在部分7.1中描述的证书认证。同
时，这些能提供完整性和传输数据的泄露保护，和客户及服务的认证，包括避
免主动中间攻击。

   	如果TLS是被协商的，客户（程序）必须（MUST）丢弃所有先前TLS协商中获得的关于
服务（程序）的信息。特别是，supportedSASLMechanisms 的值可以（MAY）在TLS已经协商
之后不同（特别地，扩展（EXTERNAL）机制或者提出的明文（PLAIN）机制很可能仅在TLS
协商执行之后被列举出来）。

   	如果SASL安全层（security layer）被协商，客户（程序）必须（MUST）丢弃所有先前
SASL中获得的关于服务（程序）的信息。特别是，如果客户（程序）被配置为支持多（multiple）
SASL机制，它应该（SHOULD）在SASL安全层被协商之前和之后获得supportedSASLMechanisms
并且验证其值在SASL安全层协商之后没有改变。这个探测从supportedSASLMechanisms列表
中移去支持的SASL机制的主动攻击，并且允许客户确保它使用的由客户和服务都支持的最好
的机制（另外，这个应该（SHOULD）允许支持SASL机制列表的环境对客户提供通过不同的信
任源（trusted source），例如，数字签名对象（digitally signed object）的一部分）。 

5. 匿名认证
   	其修改实体或者存取受保护的属性或实体通常需要客户的认证。没有打算执行任何这些
操作的客户典型的使用匿名认证。

   	LDAP工具必须（MUST）支持匿名认证，在部分5.1中定义。

   	LDAP工具可以（MAY）支持同TLS的匿名认证，在部分5.2中定义。

   	当可能（MAY）有存取控制限制（access control restrictions）阻碍目录实体的存取
时，LDAP服务应该（SHOULD）允许匿名绑定（anonymously-bound）的客户检索（retrieve）
根（root）DSE的supportedSASLMechanisms属性。

   	LDAP服务可以（MAY）使用关于客户通过低层（lower layers）（网络协议）或者扩展的
授权（grant）或拒绝（deny）存取完全（控制）给匿名认证的客户的其他信息。

5.1. 匿名认证过程
   	一LDAP客户其还没有成功完成在连接之上的绑定操作是匿名地认证。

   	一LDAP客户也可以（MAY）具体通过使用简单的认证选择的零长度（zero-length）OCTET 
STRING 绑定需求中指定匿名认证。

5.2. 匿名认证和TLS
   	LDAP客户（程序）可以（MAY）使用启动TLS操作[5]去协商TLS安全的使用[6]。如果
客户还没有预先绑定，那么直到客户使用EXTERNAL SASL机制去协商客户证书的识别
（recognition），客户是匿名地认证。

   	推荐的TLS密码组在部分10中给出。

   	LDAP服务在TLS协商过程中要求客户提供它们的证书，如果客户还没有一个有效证书时，
可以（MAY）使用本地安全策略去决定是否成功地完成TLS协商。

6. 基于口令的认证
   	LDAP工具必须（MUST）支持使用文摘MD5（DIGEST-MD5）SASL机制（保护口令）的口令
认证，在部分6.1中定义。

   	当使用TLS保护连接防止被监听时，LDAP工具应该（SHOULD）支持"simple"口令选择认
证 ，在部分6.2中定义。

6.1. 文摘认证
   	LDAP客户可以通过在根DSE之上执行搜索请求、请求supportedSASLMechanisms属性、
以及检查是否字符串"DIGEST-MD5"作为值存在于这个属性中来判定是否服务支持这个机制。

   	在认证的第一阶段，当客户正在执行在[4]部分2.1中定义的"initial authentication"
（初始化认证）时，客户发送请求绑定，其版本数字是3、认证选择（authentication choice）
是sasl、sasl机制名字是"DIGEST-MD5"、以及证明（credentials）不在场。客户然后等待
服务对这个请求做出的回答。 

   	服务将以resultCode 是saslBindInProgress 、以及serverSaslCreds字段存在的绑定
回答做出回答。这个字段的内容是在[4]部分2.1.1中定义的字符串。服务应该（SHOULD）包
括域指示（MUST）和必须指明支持UTF-8。

   	客户将发送有区别报文id（distinct message id）的绑定请求，其版本数字是3、认证
选择是sasl 、sasl机制名字是"DIGEST-MD5"，以及证明包含在[4]部分2.1.2中
"digest-response" 定义的字符串。serv-type是"ldap"。

   	服务将回答其resultCode 或者是成功，或者是错误指示（error indication）的回答
绑定。如果认证是成功的和服务不支持随后的（subsequent）认证，那么证明字段中包含[4]
部分2.1.3 中"response-auth"定义的字符串。在客户和服务之间支持随后的认证是可选的
（OPTIONAL）。

6.2. TLS加密下的简单认证选择（"simple" authentication 
choice）
   	一个拥有包含用户口令（userPassword）属性的目录实体可以（MAY）通过执行简单口令
绑定序列验证到目录，其随着TLS密码适配组（ciphersuite）提供的机密连接[6]的协商进
行。

   	客户将使用启动TLS操作[5]去协商在连接到LDAP服务之上的TLS安全[6]的使用。客户
不需要事先已绑定到目录。

   	对于这个认证过程的成功进行，客户和服务必须（MUST）协商其包含大量适当强度的加
密算法的密码适配组。在部分10中描述推荐的密码适配组。

   	随着TLS协商的成功的完成，客户必须（MUST）发送其版本数字是3、名字字段包含用
户的实体名字，和简单（"simple"）认证选择、包含口令的LDAP绑定的请求。

   	服务将对每一个在用户的实体命名中的用户口令（userPassword）属性的值和客户提出
的口令按照大小写敏感相等比较。如果比配，那么服务将发送resultCode 为成功的回答，
否则服务将发送resultCode 为invalidCredentials 的回答。

6.3. 随TLS的其它认证选择
   	随着TLS的协商，执行其没有涉及明文可再用口令的交换的SASL认证也是可能的。在这
种情况下，客户和服务不需要协商其提供机密性的密码适配组，如果仅当服务必需是数据完
整性的。

7. 基于证书的认证（Certificate-based 
authentication）
   	LDAP工具应该（SHOULD）支持在TLS中通过客户证书的认证，在部分7.1中定义。 

7.1. 随TLS基于证书的认证
   	一个拥有公/私密钥对的用户，其公钥已经被证书认证中心（Certification Authority）
签发，可以使用这个密钥对验证到目录服务，如果用户的证书被服务需求。用户的证书的主
题字段应该（SHOULD）是用户的目录实体的名字，并且证书认证中心必须被目录服务充分信
任以便（目录）服务能够处理被签发的证书（译者注：目录服务通过证书认证中心验证证书
的有效性）。关于服务（验证）有效证书路径的方法不在本文档讨论范围之内。

   	服务可以（MAY）支持其主题字段名不同于用户的目录实体名的证书映射。支持名字映射
的服务必须（MUST）有能力被配置为支持无映射证书。 

   	在连接LDAP服务之上的客户将使用启动TLS操作[5]去协商TLS安全的使用。在这之前
客户不需要已经绑定到目录。

   	在TLS协商中，服务必须（MUST）请求证书。客户将提供它的证书给服务，并且必须（MUST）
执行与提供证书相关的私有密钥的加密。

   	作为（上述身份验证的）展开将需求在传输中敏感数据的保护，客户和服务必须协商其
包含大量适当强度的加密算法的密码适配组。推荐的密码适配组在部分10中给出。

   	服务必须（MUST）验证客户的证书是有效的。服务将通常检查证书是被已知的CA签发的，
以及在客户的证书链中没有哪个证书是无效的（invalid）和被撤销（revoked）。服务做这些
检查存在几个过程。 

   	随着TLS协商的成功完成，客户将发送SASL "EXTERNAL"机制的LDAP绑定请求。

8. 其他机制
   	LDAP简单（"simple"）认证选择不适合没有网络或者传输层机密性（安全）的Internet
认证。

   	当LDAP包括本机匿名（native anonymous）和明文认证机制，"ANONYMOUS"和 "PLAIN" 
SASL机制不能同LDAP使用。如果不同于DN的形式的授权标识被客户需求，在传输中保护口
令的机制应该（SHOULD）被使用。

   	在本文档中下列基于SASL（SASL-based）的机制没有被考虑：
 	KERBEROS_V4, GSSAPI 和 SKEY.

   	扩展（"EXTERNAL"）SASL机制能够通过低层（lower layer）安全证明交换的使用用于
请求LDAP服务。如果TLS会话在制造（making）SASL扩展绑定（SASL EXTERNAL Bind）请
求之前还没有在客户和服务之间建立以及没有其他外部认证证明源（例如，IP-level 
security [8]），或者如果TLS会话建立处理期间，服务没有请求客户的认证证明，那么SASL
扩展绑定必须（MUST）以inappropriateAuthentication结果码失败。任何客户的认证和LDAP
关联的授权状态将丢失，所以LDAP关联在失败之后是在匿名状态。

9. 授权标识
   	授权标识作为在LDAP绑定请求和回答中SASL证明字段的一部分被携带。

   	当扩展（"EXTERNAL"）机制被协商时，如果证明字段存在，它包含的authzId形式的授
权标识在下面描述。

   	其他机制定义在证明字段中的授权标识的单元（location）。

   	授权标识是一个UTF-8字符集的字符串，相当于下面的ABNF [7]：

; 特有的预先定义授权（Specific predefined authorization）(authz) id模式定义
; 如下——新的模式在将来可能被定义。