Network Working Group M. Wahl
Request for Comments: 2829 Sun Microsystems, Inc.
Category: Standards Track H. Alvestrand
EDB Maxware
J. Hodges
Oblix, Inc.
R. Morgan
University of Washington
May 2000
Network Working Group M. Wahl
Request for Comments: 2829 Sun Microsystems, Inc.
Category: Standards Track H. Alvestrand
EDB Maxware
J. Hodges
Oblix, Inc.
R. Morgan
University of Washington
May 2000
Authentication Methods for LDAP
LDAP的身份验证方法
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations.
本文档指定了LDAP[1]实现中需要和推荐的安全机制的特定组合。
LDAP version 3 is a powerful access protocol for directories.
LDAP版本3是一个功能强大的目录访问协议。
It offers means of searching, fetching and manipulating directory content, and ways to access a rich set of security functions.
它提供了搜索、获取和操作目录内容的方法，以及访问一组丰富的安全功能的方法。
In order to function for the best of the Internet, it is vital that these security functions be interoperable; therefore there has to be a minimum subset of security functions that is common to all implementations that claim LDAPv3 conformance.
为了发挥互联网的最佳功能，这些安全功能的互操作性至关重要；因此，必须有一个最小的安全功能子集，这是所有声称符合LDAPv3的实现所共有的。
Basic threats to an LDAP directory service include:
LDAP目录服务的基本威胁包括：
(1) Unauthorized access to data via data-fetching operations,
(1) 通过数据提取操作对数据进行未经授权的访问，
(2) Unauthorized access to reusable client authentication information by monitoring others' access,
(2) 通过监视其他人的访问来对可重用客户端身份验证信息进行未经授权的访问，
(3) Unauthorized access to data by monitoring others' access,
(3) 通过监视他人的访问来对数据进行未经授权的访问，
(4) Unauthorized modification of data,
(4) 未经授权修改数据，
(5) Unauthorized modification of configuration,
(5) 未经授权修改配置，
(6) Unauthorized or excessive use of resources (denial of service), and
(6) 未经授权或过度使用资源（拒绝服务），以及
(7) Spoofing of directory: Tricking a client into believing that information came from the directory when in fact it did not, either by modifying data in transit or misdirecting the client's connection.
(7) 欺骗目录：通过修改传输中的数据或错误引导客户端的连接，诱使客户端相信信息来自目录，而实际上并非如此。
Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), (3) and (7) are due to hostile agents on the path between client and server, or posing as a server.
威胁（1）、（4）、（5）和（6）是由敌对客户造成的。威胁（2）、（3）和（7）是由于客户端和服务器之间的路径上的敌对代理，或伪装成服务器造成的。
The LDAP protocol suite can be protected with the following security mechanisms:
LDAP协议套件可以通过以下安全机制进行保护：
(1) Client authentication by means of the SASL [2] mechanism set, possibly backed by the TLS credentials exchange mechanism,
(1) 通过SASL[2]机制集进行客户端身份验证，可能由TLS凭据交换机制支持，
(2) Client authorization by means of access control based on the requestor's authenticated identity,
(2) 通过基于请求者身份验证的访问控制进行的客户端授权，
(3) Data integrity protection by means of the TLS protocol or data-integrity SASL mechanisms,
(3) 通过TLS协议或数据完整性SASL机制保护数据完整性，
(4) Protection against snooping by means of the TLS protocol or data-encrypting SASL mechanisms,
(4) 通过TLS协议或数据加密SASL机制防止窥探，
(5) Resource limitation by means of administrative limits on service controls, and
(5) 通过对服务控制的行政限制来限制资源，以及
(6) Server authentication by means of the TLS protocol or SASL mechanism.
(6) 通过TLS协议或SASL机制进行服务器身份验证。
At the moment, imposition of access controls is done by means outside the scope of the LDAP protocol.
目前，访问控制是通过LDAP协议范围之外的方式实施的。
In this document, the term "user" represents any application which is an LDAP client using the directory to retrieve or store information.
在本文档中，术语“用户”表示作为LDAP客户端的任何应用程序，该客户端使用目录检索或存储信息。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
The following scenarios are typical for LDAP directories on the Internet, and have different security requirements. (In the following, "sensitive" means data that will cause real damage to the owner if revealed; there may be data that is protected but not sensitive). This is not intended to be a comprehensive list, other scenarios are possible, especially on physically protected networks.
以下场景是Internet上LDAP目录的典型场景，具有不同的安全要求。（在下文中，“敏感”是指如果披露将对所有者造成实际损害的数据；可能存在受保护但不敏感的数据）。这并不是一个全面的列表，其他场景也是可能的，特别是在物理保护网络上。
(1) A read-only directory, containing no sensitive data, accessible to "anyone", and TCP connection hijacking or IP spoofing is not a problem. This directory requires no security functions except administrative service limits.
(1) 只读目录，不包含敏感数据，“任何人”都可以访问，TCP连接劫持或IP欺骗不是问题。除管理服务限制外，此目录不需要任何安全功能。
(2) A read-only directory containing no sensitive data; read access is granted based on identity. TCP connection hijacking is not currently a problem. This scenario requires a secure authentication function.
(2) 不包含敏感数据的只读目录；基于身份授予读访问权限。TCP连接劫持目前不是问题。此场景需要安全的身份验证功能。
(3) A read-only directory containing no sensitive data; and the client needs to ensure that the directory data is authenticated by the server and not modified while being returned from the server.
(3) 不包含敏感数据的只读目录；客户机需要确保目录数据由服务器进行身份验证，并且在从服务器返回时不会被修改。
(4) A read-write directory, containing no sensitive data; read access is available to "anyone", update access to properly authorized persons. TCP connection hijacking is not currently a problem. This scenario requires a secure authentication function.
(4) 读写目录，不包含敏感数据；“任何人”都可以使用读访问权限，并向适当授权的人员更新访问权限。TCP连接劫持目前不是问题。此场景需要安全的身份验证功能。
(5) A directory containing sensitive data. This scenario requires session confidentiality protection AND secure authentication.
(5) 包含敏感数据的目录。此场景需要会话机密性保护和安全身份验证。
This section defines basic terms, concepts, and interrelationships regarding authentication, authorization, credentials, and identity. These concepts are used in describing how various security approaches are utilized in client authentication and authorization.
本节定义了有关身份验证、授权、凭证和身份的基本术语、概念和相互关系。这些概念用于描述如何在客户端身份验证和授权中使用各种安全方法。
An access control policy is a set of rules defining the protection of resources, generally in terms of the capabilities of persons or other entities accessing those resources. A common expression of an access control policy is an access control list. Security objects and mechanisms, such as those described here, enable the expression of access control policies and their enforcement. Access control policies are typically expressed in terms of access control attributes as described below.
访问控制策略是定义资源保护的一组规则，通常根据访问这些资源的个人或其他实体的能力来定义。访问控制策略的常见表达式是访问控制列表。安全对象和机制（如本文所述）支持访问控制策略的表达及其实施。访问控制策略通常以访问控制属性表示，如下所述。
A request, when it is being processed by a server, may be associated with a wide variety of security-related factors (section 4.2 of [1]). The server uses these factors to determine whether and how to process the request. These are called access control factors (ACFs). They might include source IP address, encryption strength, the type of operation being requested, time of day, etc. Some factors may be specific to the request itself, others may be associated with the connection via which the request is transmitted, others (e.g. time of day) may be "environmental".
当服务器处理请求时，请求可能与多种安全相关因素有关（见[1]第4.2节）。服务器使用这些因素来确定是否以及如何处理请求。这些被称为访问控制因素（ACF）。它们可能包括源IP地址、加密强度、请求的操作类型、一天中的时间等。一些因素可能特定于请求本身，其他因素可能与发送请求的连接有关，其他因素（例如一天中的时间）可能是“环境因素”。
Access control policies are expressed in terms of access control factors. E.g., a request having ACFs i,j,k can perform operation Y on resource Z. The set of ACFs that a server makes available for such expressions is implementation-specific.
访问控制策略用访问控制因素表示。例如，具有ACFs i、j、k的请求可以在资源Z上执行操作Y。服务器为此类表达式提供的ACFs集是特定于实现的。
Authentication credentials are the evidence supplied by one party to another, asserting the identity of the supplying party (e.g. a user) who is attempting to establish an association with the other party (typically a server). Authentication is the process of generating, transmitting, and verifying these credentials and thus the identity they assert. An authentication identity is the name presented in a credential.
身份验证凭据是一方向另一方提供的证据，用于断言试图与另一方（通常是服务器）建立关联的提供方（例如用户）的身份。身份验证是生成、传输和验证这些凭据的过程，从而验证它们所声明的身份。身份验证标识是凭证中显示的名称。
There are many forms of authentication credentials -- the form used depends upon the particular authentication mechanism negotiated by the parties. For example: X.509 certificates, Kerberos tickets, simple identity and password pairs. Note that an authentication mechanism may constrain the form of authentication identities used with it.
身份验证凭据有多种形式——使用的形式取决于双方协商的特定身份验证机制。例如：X.509证书、Kerberos票据、简单标识和密码对。请注意，身份验证机制可能会约束与其一起使用的身份验证标识的形式。
An authorization identity is one kind of access control factor. It is the name of the user or other entity that requests that operations be performed. Access control policies are often expressed in terms of authorization identities; e.g., entity X can perform operation Y on resource Z.
授权标识是一种访问控制因素。它是请求执行操作的用户或其他实体的名称。访问控制策略通常以授权身份表示；e、 例如，实体X可以对资源Z执行操作Y。
The authorization identity bound to an association is often exactly the same as the authentication identity presented by the client, but it may be different. SASL allows clients to specify an authorization identity distinct from the authentication identity asserted by the client's credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying [2]. Also, the form of authentication identity supplied by a service like TLS may not correspond to the authorization identities used to express a server's access control policy, requiring a server-specific mapping to be done. The method by which a server composes and validates an authorization identity from the authentication credentials supplied by a client is implementation-specific.
绑定到关联的授权标识通常与客户端提供的身份验证标识完全相同，但可能不同。SASL允许客户端指定不同于客户端凭据断言的身份验证标识的授权标识。这允许代理服务器（如代理服务器）使用其自己的凭据进行身份验证，同时请求其代理的身份的访问权限[2]。此外，由类似TLS的服务提供的身份验证身份的形式可能与用于表示服务器的访问控制策略的授权身份不对应，这需要进行特定于服务器的映射。服务器根据客户端提供的身份验证凭据组合和验证授权标识的方法是特定于实现的。
It is clear that allowing any implementation, faced with the above requirements, to pick and choose among the possible alternatives is not a strategy that is likely to lead to interoperability. In the absence of mandates, clients will be written that do not support any security function supported by the server, or worse, support only mechanisms like cleartext passwords that provide clearly inadequate security.
很明显，面对上述需求，允许任何实现在可能的备选方案中进行选择，并不是一种可能导致互操作性的策略。在没有授权的情况下，将编写不支持服务器支持的任何安全功能的客户端，或者更糟糕的是，只支持提供明显不充分安全性的明文密码等机制。
Active intermediary attacks are the most difficult for an attacker to perform, and for an implementation to protect against. Methods that protect only against hostile client and passive eavesdropping attacks are useful in situations where the cost of protection against active intermediary attacks is not justified based on the perceived risk of active intermediary attacks.
主动中间层攻击是攻击者最难执行的攻击，也是实现最难防范的攻击。仅针对恶意客户端攻击和被动窃听攻击进行保护的方法在主动中介攻击的保护成本无法基于主动中介攻击的感知风险进行调整的情况下非常有用。
Given the presence of the Directory, there is a strong desire to see mechanisms where identities take the form of a Distinguished Name and authentication data can be stored in the directory; this means that either this data is useless for faking authentication (like the Unix "/etc/passwd" file format used to be), or its content is never passed across the wire unprotected - that is, it's either updated outside the protocol or it is only updated in sessions well protected against snooping. It is also desirable to allow authentication methods to
鉴于目录的存在，人们强烈希望看到这样的机制：身份以可分辨名称的形式出现，并且认证数据可以存储在目录中；这意味着，要么这些数据对于伪造身份验证毫无用处（如过去的Unix“/etc/passwd”文件格式），要么其内容永远不会在未受保护的情况下通过网络传递——也就是说，它要么在协议之外更新，要么只在保护良好的防窥探会话中更新。还希望允许使用身份验证方法
carry authorization identities based on existing forms of user identities for backwards compatibility with non-LDAP-based authentication services.
基于现有形式的用户身份携带授权身份，以便与非基于LDAP的身份验证服务向后兼容。
Therefore, the following implementation conformance requirements are in place:
因此，制定了以下实施合规性要求：
(1) For a read-only, public directory, anonymous authentication, described in section 5, can be used.
(1) 对于只读公共目录，可以使用第5节中描述的匿名身份验证。
(2) Implementations providing password-based authenticated access MUST support authentication using the DIGEST-MD5 SASL mechanism [4], as described in section 6.1. This provides client authentication with protection against passive eavesdropping attacks, but does not provide protection against active intermediary attacks.
(2) 提供基于密码的身份验证访问的实现必须支持使用DIGEST-MD5 SASL机制进行身份验证[4]，如第6.1节所述。这为客户端身份验证提供了针对被动窃听攻击的保护，但不提供针对主动中介攻击的保护。
(3) For a directory needing session protection and authentication, the Start TLS extended operation [5], and either the simple authentication choice or the SASL EXTERNAL mechanism, are to be used together. Implementations SHOULD support authentication with a password as described in section 6.2, and SHOULD support authentication with a certificate as described in section 7.1. Together, these can provide integrity and disclosure protection of transmitted data, and authentication of client and server, including protection against active intermediary attacks.
(3) 对于需要会话保护和身份验证的目录，启动TLS扩展操作[5]和简单身份验证选项或SASL外部机制将一起使用。实现应支持使用第6.2节所述的密码进行身份验证，并应支持使用第7.1节所述的证书进行身份验证。总之，它们可以提供传输数据的完整性和披露保护，以及客户端和服务器的身份验证，包括针对主动中介攻击的保护。
If TLS is negotiated, the client MUST discard all information about the server fetched prior to the TLS negotiation. In particular, the value of supportedSASLMechanisms MAY be different after TLS has been negotiated (specifically, the EXTERNAL mechanism or the proposed PLAIN mechanism are likely to only be listed after a TLS negotiation has been performed).
如果TLS已协商，则客户端必须放弃在TLS协商之前获取的有关服务器的所有信息。特别是，TLS协商后，SupportedSaslMechanism的价值可能会有所不同（具体而言，外部机制或建议的普通机制可能仅在TLS协商完成后才会列出）。
If a SASL security layer is negotiated, the client MUST discard all information about the server fetched prior to SASL. In particular, if the client is configured to support multiple SASL mechanisms, it SHOULD fetch supportedSASLMechanisms both before and after the SASL security layer is negotiated and verify that the value has not changed after the SASL security layer was negotiated. This detects active attacks which remove supported SASL mechanisms from the supportedSASLMechanisms list, and allows the client to ensure that it is using the best mechanism supported by both client and server (additionally, this is a SHOULD to allow for environments where the supported SASL mechanisms list is provided to the client through a different trusted source, e.g. as part of a digitally signed object).
如果协商SASL安全层，则客户端必须放弃在SASL之前获取的有关服务器的所有信息。特别是，如果客户机被配置为支持多个SASL机制，那么它应该在SASL安全层协商之前和之后获取SupportedSASLMechanism，并验证该值在SASL安全层协商之后没有更改。这会检测到主动攻击，这些攻击会从supportedSASLMechanisms列表中删除受支持的SASL机制，并允许客户端确保使用客户端和服务器都支持的最佳机制（此外，对于通过不同的受信任源（例如，作为数字签名对象的一部分）向客户端提供受支持的SASL机制列表的环境，这是一个应该考虑的问题）。
Directory operations which modify entries or access protected attributes or entries generally require client authentication. Clients which do not intend to perform any of these operations typically use anonymous authentication.
修改条目或访问受保护属性或条目的目录操作通常需要客户端身份验证。不打算执行这些操作的客户端通常使用匿名身份验证。
LDAP implementations MUST support anonymous authentication, as defined in section 5.1.
LDAP实现必须支持匿名身份验证，如第5.1节所定义。
LDAP implementations MAY support anonymous authentication with TLS, as defined in section 5.2.
LDAP实现可能支持TLS的匿名身份验证，如第5.2节所定义。
While there MAY be access control restrictions to prevent access to directory entries, an LDAP server SHOULD allow an anonymously-bound client to retrieve the supportedSASLMechanisms attribute of the root DSE.
虽然可能存在访问控制限制以阻止对目录项的访问，但LDAP服务器应允许匿名绑定的客户端检索根DSE的supportedSASLMechanisms属性。
An LDAP server MAY use other information about the client provided by the lower layers or external means to grant or deny access even to anonymously authenticated clients.
LDAP服务器可以使用较低层提供的关于客户端的其他信息或外部手段来授予或拒绝访问，即使是匿名认证的客户端。
An LDAP client which has not successfully completed a bind operation on a connection is anonymously authenticated.
对未成功完成连接绑定操作的LDAP客户端进行匿名身份验证。
An LDAP client MAY also specify anonymous authentication in a bind request by using a zero-length OCTET STRING with the simple authentication choice.
LDAP客户端还可以通过使用具有简单身份验证选项的零长度八位字节字符串在绑定请求中指定匿名身份验证。
An LDAP client MAY use the Start TLS operation [5] to negotiate the use of TLS security [6]. If the client has not bound beforehand, then until the client uses the EXTERNAL SASL mechanism to negotiate the recognition of the client's certificate, the client is anonymously authenticated.
LDAP客户端可以使用启动TLS操作[5]来协商TLS安全性的使用[6]。如果客户端事先没有绑定，则在客户端使用外部SASL机制协商对客户端证书的识别之前，客户端将进行匿名身份验证。
Recommendations on TLS ciphersuites are given in section 10.
第10节给出了关于TLS密码套件的建议。
An LDAP server which requests that clients provide their certificate during TLS negotiation MAY use a local security policy to determine whether to successfully complete TLS negotiation if the client did not present a certificate which could be validated.
请求客户端在TLS协商期间提供其证书的LDAP服务器可以使用本地安全策略来确定如果客户端未提供可验证的证书，是否成功完成TLS协商。
LDAP implementations MUST support authentication with a password using the DIGEST-MD5 SASL mechanism for password protection, as defined in section 6.1.
LDAP实现必须支持使用DIGEST-MD5 SASL机制进行密码保护的密码身份验证，如第6.1节所定义。
LDAP implementations SHOULD support authentication with the "simple" password choice when the connection is protected against eavesdropping using TLS, as defined in section 6.2.
如第6.2节所定义，当使用TLS防止连接被窃听时，LDAP实现应支持使用“简单”密码选择的身份验证。
An LDAP client MAY determine whether the server supports this mechanism by performing a search request on the root DSE, requesting the supportedSASLMechanisms attribute, and checking whether the string "DIGEST-MD5" is present as a value of this attribute.
LDAP客户端可以通过对根DSE执行搜索请求、请求supportedSASLMechanisms属性并检查字符串“DIGEST-MD5”是否作为该属性的值存在来确定服务器是否支持此机制。
In the first stage of authentication, when the client is performing an "initial authentication" as defined in section 2.1 of [4], the client sends a bind request in which the version number is 3, the authentication choice is sasl, the sasl mechanism name is "DIGEST-MD5", and the credentials are absent. The client then waits for a response from the server to this request.
在身份验证的第一阶段，当客户端执行[4]第2.1节中定义的“初始身份验证”时，客户端发送绑定请求，其中版本号为3，身份验证选项为sasl，sasl机制名称为“DIGEST-MD5”，并且没有凭据。然后，客户机等待服务器对此请求的响应。
The server will respond with a bind response in which the resultCode is saslBindInProgress, and the serverSaslCreds field is present. The contents of this field is a string defined by "digest-challenge" in section 2.1.1 of [4]. The server SHOULD include a realm indication and MUST indicate support for UTF-8.
服务器将使用绑定响应进行响应，其中resultCode为saslBindInProgress，并且存在serversaslclreds字段。此字段的内容是由[4]第2.1.1节中的“摘要质询”定义的字符串。服务器应该包括领域指示，并且必须指示对UTF-8的支持。
The client will send a bind request with a distinct message id, in which the version number is 3, the authentication choice is sasl, the sasl mechanism name is "DIGEST-MD5", and the credentials contain the string defined by "digest-response" in section 2.1.2 of [4]. The serv-type is "ldap".
客户端将发送一个具有不同消息id的绑定请求，其中版本号为3，身份验证选项为sasl，sasl机制名称为“DIGEST-MD5”，凭据包含[4]第2.1.2节中“DIGEST response”定义的字符串。服务类型是“ldap”。
The server will respond with a bind response in which the resultCode is either success, or an error indication. If the authentication is successful and the server does not support subsequent authentication, then the credentials field is absent. If the authentication is successful and the server supports subsequent authentication, then the credentials field contains the string defined by "response-auth" in section 2.1.3 of [4]. Support for subsequent authentication is OPTIONAL in clients and servers.
服务器将使用绑定响应进行响应，其中resultCode为success或错误指示。如果身份验证成功，并且服务器不支持后续身份验证，则凭据字段不存在。如果身份验证成功且服务器支持后续身份验证，则凭证字段包含由[4]第2.1.3节中的“响应身份验证”定义的字符串。在客户端和服务器中，对后续身份验证的支持是可选的。
A user who has a directory entry containing a userPassword attribute MAY authenticate to the directory by performing a simple password bind sequence following the negotiation of a TLS ciphersuite providing connection confidentiality [6].
具有包含userPassword属性的目录条目的用户可以通过在提供连接机密性的TLS ciphersuite协商之后执行简单的密码绑定序列来对目录进行身份验证[6]。
The client will use the Start TLS operation [5] to negotiate the use of TLS security [6] on the connection to the LDAP server. The client need not have bound to the directory beforehand.
客户端将使用启动TLS操作[5]协商在与LDAP服务器的连接上使用TLS安全[6]。客户端不需要事先绑定到目录。
For this authentication procedure to be successful, the client and server MUST negotiate a ciphersuite which contains a bulk encryption algorithm of appropriate strength. Recommendations on cipher suites are given in section 10.
要使此身份验证过程成功，客户端和服务器必须协商一个包含适当强度的批量加密算法的密码套件。第10节给出了关于密码套件的建议。
Following the successful completion of TLS negotiation, the client MUST send an LDAP bind request with the version number of 3, the name field containing the name of the user's entry, and the "simple" authentication choice, containing a password.
成功完成TLS协商后，客户端必须发送版本号为3的LDAP绑定请求、包含用户条目名称的名称字段和包含密码的“简单”身份验证选项。
The server will, for each value of the userPassword attribute in the named user's entry, compare these for case-sensitive equality with the client's presented password. If there is a match, then the server will respond with resultCode success, otherwise the server will respond with resultCode invalidCredentials.
对于命名用户条目中的userPassword属性的每个值，服务器将比较它们与客户端提供的密码是否大小写敏感。如果存在匹配项，则服务器将以resultCode success响应，否则服务器将以resultCode invalidCredentials响应。
It is also possible, following the negotiation of TLS, to perform a SASL authentication which does not involve the exchange of plaintext reusable passwords. In this case the client and server need not negotiate a ciphersuite which provides confidentiality if the only service required is data integrity.
在TLS协商之后，还可以执行SASL认证，该认证不涉及明文可重用密码的交换。在这种情况下，如果只需要数据完整性服务，客户机和服务器不需要协商提供机密性的密码套件。
LDAP implementations SHOULD support authentication via a client certificate in TLS, as defined in section 7.1.
LDAP实现应支持通过TLS中的客户端证书进行身份验证，如第7.1节所定义。
A user who has a public/private key pair in which the public key has been signed by a Certification Authority may use this key pair to authenticate to the directory server if the user's certificate is requested by the server. The user's certificate subject field SHOULD be the name of the user's directory entry, and the Certification Authority must be sufficiently trusted by the directory server to
如果服务器请求用户的证书，则拥有公钥已由证书颁发机构签名的公钥/私钥对的用户可以使用该密钥对向目录服务器进行身份验证。用户的证书主题字段应该是用户目录项的名称，并且目录服务器必须充分信任证书颁发机构以
have issued the certificate in order that the server can process the certificate. The means by which servers validate certificate paths is outside the scope of this document.
已颁发证书，以便服务器可以处理该证书。服务器验证证书路径的方法超出了本文档的范围。
A server MAY support mappings for certificates in which the subject field name is different from the name of the user's directory entry. A server which supports mappings of names MUST be capable of being configured to support certificates for which no mapping is required.
服务器可能支持对主题字段名称不同于用户目录项名称的证书的映射。支持名称映射的服务器必须能够配置为支持不需要映射的证书。
The client will use the Start TLS operation [5] to negotiate the use of TLS security [6] on the connection to the LDAP server. The client need not have bound to the directory beforehand.
客户端将使用启动TLS操作[5]协商在与LDAP服务器的连接上使用TLS安全[6]。客户端不需要事先绑定到目录。
In the TLS negotiation, the server MUST request a certificate. The client will provide its certificate to the server, and MUST perform a private key-based encryption, proving it has the private key associated with the certificate.
在TLS协商中，服务器必须请求证书。客户端将向服务器提供其证书，并且必须执行基于私钥的加密，以证明其具有与证书关联的私钥。
As deployments will require protection of sensitive data in transit, the client and server MUST negotiate a ciphersuite which contains a bulk encryption algorithm of appropriate strength. Recommendations of cipher suites are given in section 10.
由于部署需要保护传输中的敏感数据，客户端和服务器必须协商一个包含适当强度的批量加密算法的密码套件。第10节给出了密码套件的建议。
The server MUST verify that the client's certificate is valid. The server will normally check that the certificate is issued by a known CA, and that none of the certificates on the client's certificate chain are invalid or revoked. There are several procedures by which the server can perform these checks.
服务器必须验证客户端的证书是否有效。服务器通常会检查证书是否由已知CA颁发，以及客户端证书链上的证书是否无效或已吊销。服务器可以通过几个过程执行这些检查。
Following the successful completion of TLS negotiation, the client will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
成功完成TLS协商后，客户端将使用SASL“外部”机制发送LDAP绑定请求。
The LDAP "simple" authentication choice is not suitable for authentication on the Internet where there is no network or transport layer confidentiality.
LDAP“简单”身份验证选项不适合在没有网络或传输层机密性的Internet上进行身份验证。
As LDAP includes native anonymous and plaintext authentication methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used with LDAP. If an authorization identity of a form different from a DN is requested by the client, a mechanism that protects the password in transit SHOULD be used.
由于LDAP包括本机匿名和明文身份验证方法，因此LDAP不使用“匿名”和“普通”SASL机制。如果客户端请求不同于DN的形式的授权标识，则应使用保护传输中的密码的机制。
The following SASL-based mechanisms are not considered in this document: KERBEROS_V4, GSSAPI and SKEY.
本文不考虑以下基于SASL的机制：KERBEROS_V4、GSSAPI和SKEY。
The "EXTERNAL" SASL mechanism can be used to request the LDAP server make use of security credentials exchanged by a lower layer. If a TLS session has not been established between the client and server prior to making the SASL EXTERNAL Bind request and there is no other external source of authentication credentials (e.g. IP-level security [8]), or if, during the process of establishing the TLS session, the server did not request the client's authentication credentials, the SASL EXTERNAL bind MUST fail with a result code of inappropriateAuthentication. Any client authentication and authorization state of the LDAP association is lost, so the LDAP association is in an anonymous state after the failure.
“外部”SASL机制可用于请求LDAP服务器使用较低层交换的安全凭据。如果在发出SASL外部绑定请求之前，尚未在客户端和服务器之间建立TLS会话，并且没有其他外部身份验证凭据来源（例如，IP级别安全[8]），或者如果在建立TLS会话的过程中，服务器未请求客户端的身份验证凭据，SASL外部绑定必须失败，结果代码为不正确的身份验证。LDAP关联的任何客户端身份验证和授权状态都将丢失，因此失败后LDAP关联处于匿名状态。
The authorization identity is carried as part of the SASL credentials field in the LDAP Bind request and response.
授权标识作为LDAP绑定请求和响应中SASL凭据字段的一部分携带。
When the "EXTERNAL" mechanism is being negotiated, if the credentials field is present, it contains an authorization identity of the authzId form described below.
协商“外部”机制时，如果存在凭据字段，则它包含下面描述的authzId表单的授权标识。
Other mechanisms define the location of the authorization identity in the credentials field.
其他机制在凭证字段中定义授权标识的位置。
The authorization identity is a string in the UTF-8 character set, corresponding to the following ABNF [7]:
授权标识是UTF-8字符集中的字符串，对应于以下ABNF[7]：
; Specific predefined authorization (authz) id schemes are ; defined below -- new schemes may be defined in the future.
; 特定的预定义授权（authz）id方案包括：；定义如下——未来可能会定义新方案。
authzId = dnAuthzId / uAuthzId
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
dn = utf8string ; with syntax defined in RFC 2253
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
dn = utf8string ; with syntax defined in RFC 2253
; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
A utf8string is defined to be the UTF-8 encoding of one or more ISO 10646 characters.
utf8string定义为一个或多个ISO10646字符的UTF-8编码。
All servers which support the storage of authentication credentials, such as passwords or certificates, in the directory MUST support the dnAuthzId choice.
所有支持在目录中存储身份验证凭据（如密码或证书）的服务器都必须支持dnAuthzId选项。
The uAuthzId choice allows for compatibility with client applications which wish to authenticate to a local directory but do not know their own Distinguished Name or have a directory entry. The format of the string is defined as only a sequence of UTF-8 encoded ISO 10646 characters, and further interpretation is subject to prior agreement between the client and server.
uAuthzId选项允许与希望对本地目录进行身份验证但不知道自己的可分辨名称或具有目录项的客户端应用程序兼容。该字符串的格式仅定义为UTF-8编码的ISO10646字符序列，进一步的解释须经客户机和服务器事先同意。
For example, the userid could identify a user of a specific directory service, or be a login name or the local-part of an RFC 822 email address. In general a uAuthzId MUST NOT be assumed to be globally unique.
例如，userid可以标识特定目录服务的用户，或者是登录名或rfc822电子邮件地址的本地部分。一般情况下，不得假设uAuthzId是全局唯一的。
Additional authorization identity schemes MAY be defined in future versions of this document.
其他授权标识方案可在本文件的未来版本中定义。
The following ciphersuites defined in [6] MUST NOT be used for confidentiality protection of passwords or data:
[6]中定义的以下密码套件不得用于密码或数据的保密保护：
TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA
TLS\U NULL\U NULL\U NULL TLS\U RSA\U NULL\U MD5 TLS\U RSA\U NULL\U SHA
The following ciphersuites defined in [6] can be cracked easily (less than a week of CPU time on a standard CPU in 1997). The client and server SHOULD carefully consider the value of the password or data being protected before using these ciphersuites:
[6]中定义的以下密码套件很容易被破解（1997年标准CPU的CPU时间不足一周）。在使用这些密码子之前，客户端和服务器应该仔细考虑密码或数据的值：
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
4月4月4月4月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10月10日，RSA基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金会基金RC4\u 40\u MD5 TLS\u DH\u anon\u出口与CBC\u SHA
The following ciphersuites are vulnerable to man-in-the-middle attacks, and SHOULD NOT be used to protect passwords or sensitive data, unless the network configuration is such that the danger of a man-in-the-middle attack is tolerable:
以下密码套件容易受到中间人攻击，不应用于保护密码或敏感数据，除非网络配置允许中间人攻击的危险：
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
TLS\u DH_anon\u出口带RC4\u 40\u MD5 TLS\u DH_anon\u出口带RC4\u 128\u MD5 TLS\u DH_anon\u出口带CBC\u SHA TLS\u DH_anon\u
A client or server that supports TLS MUST support at least TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
支持TLS的客户端或服务器必须至少支持TLS\u DHE\u DSS\u和\u 3DES\u EDE\u CBC\u SHA。
For use with SASL [2], a protocol must specify a service name to be used with various SASL mechanisms, such as GSSAPI. For LDAP, the service name is "ldap", which has been registered with the IANA as a GSSAPI service name.
对于与SASL[2]一起使用，协议必须指定要与各种SASL机制（如GSSAPI）一起使用的服务名称。对于LDAP，服务名称为“LDAP”，它已作为GSSAPI服务名称在IANA注册。
Security issues are discussed throughout this memo; the (unsurprising) conclusion is that mandatory security is important, and that session encryption is required when snooping is a problem.
本备忘录中讨论了安全问题；（毫不奇怪）的结论是，强制安全性很重要，当窥探是一个问题时，会话加密是必需的。
Servers are encouraged to prevent modifications by anonymous users. Servers may also wish to minimize denial of service attacks by timing out idle connections, and returning the unwillingToPerform result code rather than performing computationally expensive operations requested by unauthorized clients.
鼓励服务器防止匿名用户进行修改。服务器还可能希望通过超时空闲连接、返回不情愿的操作结果代码，而不是执行未经授权的客户端请求的计算代价高昂的操作，来最大限度地减少拒绝服务攻击。
A connection on which the client has not performed the Start TLS operation or negotiated a suitable SASL mechanism for connection integrity and encryption services is subject to man-in-the-middle attacks to view and modify information in transit.
客户端未执行Start TLS操作或未协商连接完整性和加密服务的适当SASL机制的连接会受到中间人攻击，以查看和修改传输中的信息。
Additional security considerations relating to the EXTERNAL mechanism to negotiate TLS can be found in [2], [5] and [6].
[2]、[5]和[6]中可以找到与协商TLS的外部机制有关的其他安全注意事项。
This document is a product of the LDAPEXT Working Group of the IETF. The contributions of its members is greatly appreciated.
本文件是IETF LDAPEXT工作组的产品。非常感谢其成员的贡献。
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[1] Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[2] 迈尔斯，J.，“简单认证和安全层（SASL）”，RFC2222，1997年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[4] Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[5] Hodges，J.，Morgan，R.和M.Wahl，“轻量级目录访问协议（v3）：传输层安全扩展”，RFC 2830，2000年5月。
[6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[6] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[8] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[8] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
Mark Wahl Sun Microsystems, Inc. 8911 Capital of Texas Hwy #4140 Austin TX 78759 USA
Mark Wahl Sun Microsystems，Inc.8911美国德克萨斯州奥斯汀市德克萨斯Hwy#4140首府，邮编78759
EMail: M.Wahl@innosoft.com
EMail: M.Wahl@innosoft.com
Harald Tveit Alvestrand EDB Maxware Pirsenteret N-7462 Trondheim, Norway
挪威特隆赫姆Harald Tveit Alvestrand EDB Maxware Pirsenteret N-7462
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no
Jeff Hodges Oblix, Inc. 18922 Forge Drive Cupertino, CA 95014 USA
Jeff Hodges Oblix，Inc.18922美国加利福尼亚州库珀蒂诺锻造大道95014号
Phone: +1-408-861-6656
EMail: JHodges@oblix.com
Phone: +1-408-861-6656
EMail: JHodges@oblix.com
RL "Bob" Morgan Computing and Communications University of Washington Seattle, WA 98105 USA
摩根西雅图华盛顿大学计算与通信学院，美国98105
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。