Network Working Group J. Hodges
Request for Comments: 2830 Oblix Inc.
Category: Standards Track R. Morgan
Univ of Washington
M. Wahl
Sun Microsystems, Inc.
May 2000
Network Working Group J. Hodges
Request for Comments: 2830 Oblix Inc.
Category: Standards Track R. Morgan
Univ of Washington
M. Wahl
Sun Microsystems, Inc.
May 2000
Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
轻量级目录访问协议（v3）：传输层安全性的扩展
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 defines the "Start Transport Layer Security (TLS) Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of an LDAP extended request.
本文档定义了LDAP[LDAPv3，TLS]的“启动传输层安全（TLS）操作”。此操作用于在LDAP关联中建立TLS，并根据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 [ReqsKeywords].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[ReqsKeywords]中所述进行解释。
This section describes the Start TLS extended request and extended response themselves: how to form the request, the form of the response, and enumerates the various result codes the client MUST be prepared to handle.
本节介绍Start TLS扩展请求和扩展响应本身：如何形成请求、响应的形式，并列举客户端必须准备好处理的各种结果代码。
The section following this one then describes how to sequence an overall Start TLS Operation.
接下来的章节将描述如何对整个启动TLS操作进行排序。
A client may perform a Start TLS operation by transmitting an LDAP PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the Start TLS operation:
客户端可以通过传输包含ExtendedRequest[LDAPv3]的LDAP PDU来执行启动TLS操作，该请求指定启动TLS操作的OID：
1.3.6.1.4.1.1466.20037
1.3.6.1.4.1.1466.20037
An LDAP ExtendedRequest is defined as follows:
LDAP ExtendedRequest的定义如下：
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
A Start TLS extended request is formed by setting the requestName field to the OID string given above. The requestValue field is absent. The client MUST NOT send any PDUs on this connection following this request until it receives a Start TLS extended response.
通过将requestName字段设置为上面给出的OID字符串，可以形成Start TLS扩展请求。缺少requestValue字段。在收到Start TLS extended响应之前，客户端不得在此连接上发送此请求之后的任何PDU。
When a Start TLS extended request is made, the server MUST return an LDAP PDU containing a Start TLS extended response. An LDAP ExtendedResponse is defined as follows:
当发出Start TLS扩展请求时，服务器必须返回包含Start TLS扩展响应的LDAP PDU。LDAP ExtendedResponse的定义如下：
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
A Start TLS extended response MUST contain a responseName field which MUST be set to the same string as that in the responseName field present in the Start TLS extended request. The response field is absent. The server MUST set the resultCode field to either success or one of the other values outlined in section 2.3.
Start TLS扩展响应必须包含responseName字段，该字段必须设置为与Start TLS扩展请求中responseName字段中的字符串相同的字符串。响应字段不存在。服务器必须将resultCode字段设置为success或第2.3节中列出的其他值之一。
If the ExtendedResponse contains a resultCode of success, this indicates that the server is willing and able to negotiate TLS. Refer to section 3, below, for details.
如果ExtendedResponse包含一个resultCode of success，则表示服务器愿意并且能够协商TLS。有关详细信息，请参阅下文第3节。
If the ExtendedResponse contains a resultCode other than success, this indicates that the server is unwilling or unable to negotiate TLS.
如果ExtendedResponse包含除success之外的resultCode，则表示服务器不愿意或无法协商TLS。
If the Start TLS extended request was not successful, the resultCode will be one of:
如果启动TLS扩展请求未成功，则结果代码将为：
operationsError (operations sequencing incorrect; e.g. TLS already established)
操作错误（操作顺序不正确；例如TLS已建立）
protocolError (TLS not supported or incorrect PDU structure)
协议错误（不支持TLS或PDU结构不正确）
referral (this server doesn't do TLS, try this one)
引用（此服务器不执行TLS，请尝试此服务器）
unavailable (e.g. some major problem with TLS, or server is shutting down)
不可用（例如，TLS出现重大问题，或服务器正在关闭）
The server MUST return operationsError if the client violates any of the Start TLS extended operation sequencing requirements described in section 3, below.
如果客户端违反下面第3节中描述的任何启动TLS扩展操作顺序要求，服务器必须返回operationsError。
If the server does not support TLS (whether by design or by current configuration), it MUST set the resultCode to protocolError (see section 4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual referral value in the LDAP Result if it returns a resultCode of referral. The client's current session is unaffected if the server does not support TLS. The client MAY proceed with any LDAP operation, or it MAY close the connection.
如果服务器不支持TLS（无论是设计还是当前配置），则必须将resultCode设置为protocolError（请参见[LDAPv3]第4.1.1节）或Reference。如果服务器返回resultCode of referral，则必须在LDAP结果中包含实际的引用值。如果服务器不支持TLS，则客户端的当前会话不受影响。客户端可以继续执行任何LDAP操作，也可以关闭连接。
The server MUST return unavailable if it supports TLS but cannot establish a TLS connection for some reason, e.g. the certificate server not responding, it cannot contact its TLS implementation, or if the server is in process of shutting down. The client MAY retry the StartTLS operation, or it MAY proceed with any other LDAP operation, or it MAY close the connection.
如果服务器支持TLS但由于某种原因无法建立TLS连接，例如证书服务器没有响应、无法联系其TLS实现，或者服务器正在关闭，则服务器必须返回“不可用”。客户端可以重试StartTLS操作，也可以继续任何其他LDAP操作，或者关闭连接。
This section describes the overall procedures clients and servers MUST follow for TLS establishment. These procedures take into consideration various aspects of the overall security of the LDAP association including discovery of resultant security level and assertion of the client's authorization identity.
本节描述了客户机和服务器建立TLS必须遵循的总体程序。这些过程考虑了LDAP关联的整体安全性的各个方面，包括发现结果安全级别和断言客户端的授权标识。
Note that the precise effects, on a client's authorization identity, of establishing TLS on an LDAP association are described in detail in section 5.
请注意，在LDAP关联上建立TLS对客户端授权标识的确切影响将在第5节中详细描述。
The client MAY send the Start TLS extended request at any time after establishing an LDAP association, except that in the following cases the client MUST NOT send a Start TLS extended request:
在建立LDAP关联后，客户端可以随时发送Start TLS扩展请求，但在以下情况下，客户端不得发送Start TLS扩展请求：
- if TLS is currently established on the connection, or - during a multi-stage SASL negotiation, or - if there are any LDAP operations outstanding on the connection.
- 如果当前在连接上建立了TLS，或者-在多阶段SASL协商期间，或者-如果连接上存在任何未完成的LDAP操作。
The result of violating any of these requirements is a resultCode of operationsError, as described above in section 2.3.
如上文第2.3节所述，违反这些要求的结果是操作错误的结果代码。
The client MAY have already performed a Bind operation when it sends a Start TLS request, or the client might have not yet bound.
客户端可能在发送Start TLS请求时已执行绑定操作，或者客户端可能尚未绑定。
If the client did not establish a TLS connection before sending any other requests, and the server requires the client to establish a TLS connection before performing a particular request, the server MUST reject that request with a confidentialityRequired or strongAuthRequired result. The client MAY send a Start TLS extended request, or it MAY choose to close the connection.
如果客户端在发送任何其他请求之前未建立TLS连接，并且服务器要求客户端在执行特定请求之前建立TLS连接，则服务器必须以机密性要求或strongAuthRequired结果拒绝该请求。客户端可以发送启动TLS扩展请求，也可以选择关闭连接。
The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable.
如果服务器愿意并且能够协商TLS，它将返回一个扩展响应，结果代码为success。如果无法返回，它将返回上面记录的其他resultCodes。
In the successful case, the client, which has ceased to transfer LDAP requests on the connection, MUST either begin a TLS negotiation or close the connection. The client will send PDUs in the TLS Record Protocol directly over the underlying transport connection to the server to initiate TLS negotiation [TLS].
在成功的情况下，已停止在连接上传输LDAP请求的客户端必须开始TLS协商或关闭连接。客户端将通过底层传输连接直接向服务器发送TLS记录协议中的PDU，以启动TLS协商[TLS]。
Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in [TLS]. Please refer to that document for details.
协商要使用的TLS或SSL版本是TLS握手协议的一部分，如[TLS]中所述。详情请参阅该文件。
After a TLS connection is established on an LDAP association, both parties MUST individually decide whether or not to continue based on the privacy level achieved. Ascertaining the TLS connection's privacy level is implementation dependent, and accomplished by communicating with one's respective local TLS implementation.
在LDAP关联上建立TLS连接后，双方必须根据获得的隐私级别分别决定是否继续。确定TLS连接的隐私级别取决于实现，并通过与各自的本地TLS实现进行通信来完成。
If the client or server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD gracefully close the TLS connection immediately after the TLS negotiation has completed (see sections 4.1 and 5.2, below).
如果客户端或服务器确定身份验证或隐私级别不够高，无法继续，则应在TLS协商完成后立即正常关闭TLS连接（见下文第4.1节和第5.2节）。
The client MAY attempt to Start TLS again, or MAY send an unbind request, or send any other LDAP request.
客户端可能会尝试再次启动TLS，或者发送解除绑定请求，或者发送任何其他LDAP请求。
The client MAY, upon receipt of a Start TLS extended response indicating success, assert that a specific authorization identity be utilized in determining the client's authorization status. The client accomplishes this via an LDAP Bind request specifying a SASL mechanism of "EXTERNAL" [SASL]. See section 5.1.2, below.
在接收到指示成功的Start-TLS扩展响应时，客户机可以断言在确定客户机的授权状态时使用特定授权标识。客户机通过指定SASL机制“EXTERNAL”[SASL]的LDAP绑定请求来实现这一点。见下文第5.1.2节。
The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
客户端必须对照服务器证书消息中显示的服务器标识检查其对服务器主机名的理解，以防止中间人攻击。
Matching is performed according to these rules:
根据以下规则执行匹配：
- The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use the server's canonical DNS name or any other derived form of name.
- 客户端必须使用用于打开LDAP连接的服务器主机名作为值，以与服务器证书中表示的服务器名称进行比较。客户端不得使用服务器的规范DNS名称或任何其他派生形式的名称。
- If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
- 如果证书中存在dNSName类型的subjectAltName扩展名，则应将其用作服务器标识的源。
- Matching is case-insensitive.
- 匹配不区分大小写。
- The "*" wildcard character is allowed. If present, it applies only to the left-most name component.
- 允许使用“*”通配符。如果存在，则仅适用于最左侧的名称组件。
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name), a match in any one of the set is considered acceptable.
例如.*.bar.com与a.bar.com、b.bar.com等匹配，但与bar.com不匹配。如果证书中存在给定类型的多个标识（例如，多个dNSName名称），则任何一个集合中的匹配都被认为是可接受的。
If the hostname does not match the dNSName-based identity in the certificate per the above check, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to
根据上述检查，如果主机名与证书中基于dNSName的标识不匹配，面向用户的客户端应通知用户（客户端可能会给用户提供
continue with the connection in any case) or terminate the connection and indicate that the server's identity is suspect. Automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect.
继续连接（在任何情况下）或终止连接，并指出服务器的身份可疑。自动客户端应关闭连接，返回和/或记录一个错误，表明服务器的身份可疑。
Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information.
除了本节所述的服务器身份检查之外，客户机还应准备进行进一步检查，以确保服务器有权提供其所提供的服务。客户可能需要使用本地策略信息。
The client MUST refresh any cached server capabilities information (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS session establishment. This is necessary to protect against active-intermediary attacks which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment.
TLS会话建立后，客户端必须刷新任何缓存的服务器功能信息（例如，从服务器的根DSE；请参阅[LDAPv3]的第3.4节）。这对于防止主动中介攻击是必要的，因为主动中介攻击可能会改变TLS建立之前检索到的任何服务器功能信息。TLS建立后，服务器可能会公布不同的功能。
Either the client or server MAY terminate the TLS connection on an LDAP association by sending a TLS closure alert. This will leave the LDAP association intact.
客户端或服务器都可以通过发送TLS关闭警报来终止LDAP关联上的TLS连接。这将使LDAP关联保持不变。
Before closing a TLS connection, the client MUST either wait for any outstanding LDAP operations to complete, or explicitly abandon them [LDAPv3].
在关闭TLS连接之前，客户端必须等待任何未完成的LDAP操作完成，或者显式放弃它们[LDAPv3]。
After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the receipt of the alert, MAY send and receive LDAP PDUs.
关闭的发起人发送关闭警报后，必须丢弃任何TLS消息，直到收到另一方的警报。它将停止发送TLS记录协议PDU，并且在收到警报后，可以发送和接收LDAP PDU。
The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs, and MAY send and receive LDAP PDUs.
另一方如果收到关闭警报，必须立即发送TLS关闭警报。它随后将停止发送TLS记录协议PDU，并可能发送和接收LDAP PDU。
Either the client or server MAY abruptly close the entire LDAP association and any TLS connection established on it by dropping the underlying TCP connection. A server MAY beforehand send the client a Notice of Disconnection [LDAPv3] in this case.
客户机或服务器可能会通过删除底层TCP连接突然关闭整个LDAP关联和在其上建立的任何TLS连接。在这种情况下，服务器可以事先向客户端发送断开连接通知[LDAPv3]。
This section describes the effects on a client's authorization identity brought about by establishing TLS on an LDAP association. The default effects are described first, and next the facilities for client assertion of authorization identity are discussed including error conditions. Lastly, the effects of closing the TLS connection are described.
本节描述在LDAP关联上建立TLS对客户端授权标识的影响。首先描述默认效果，然后讨论客户端断言授权标识的功能，包括错误条件。最后，描述了关闭TLS连接的效果。
Authorization identities and related concepts are defined in [AuthMeth].
授权标识和相关概念在[AuthMeth]中定义。
Upon establishment of the TLS connection onto the LDAP association, any previously established authentication and authorization identities MUST remain in force, including anonymous state. This holds even in the case where the server requests client authentication via TLS -- e.g. requests the client to supply its certificate during TLS negotiation (see [TLS]).
在LDAP关联上建立TLS连接后，任何先前建立的身份验证和授权标识必须保持有效，包括匿名状态。即使在服务器通过TLS请求客户端身份验证的情况下也是如此——例如，请求客户端在TLS协商期间提供其证书（请参见[TLS]）。
A client MAY either implicitly request that its LDAP authorization identity be derived from its authenticated TLS credentials or it MAY explicitly provide an authorization identity and assert that it be used in combination with its authenticated TLS credentials. The former is known as an implicit assertion, and the latter as an explicit assertion.
客户机可以隐式地请求其LDAP授权标识从其经过身份验证的TLS凭据派生，也可以显式地提供授权标识，并声明将其与经过身份验证的TLS凭据结合使用。前者称为隐式断言，后者称为显式断言。
An implicit authorization identity assertion is accomplished after TLS establishment by invoking a Bind request of the SASL form using the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include the optional credentials octet string (found within the SaslCredentials sequence in the Bind Request). The server will derive the client's authorization identity from the authentication identity supplied in the client's TLS credentials (typically a public key certificate) according to local policy. The underlying mechanics of how this is accomplished are implementation specific.
隐式授权标识断言在TLS建立后通过使用“外部”机制名称[SASL，LDAPv3]调用SASL表单的绑定请求来完成，该机制名称不应包括可选凭证八位字符串（在绑定请求中的SaslCredentials序列中找到）。服务器将根据本地策略从客户机的TLS凭据（通常是公钥证书）中提供的身份验证标识派生客户机的授权标识。如何实现这一点的基本机制是特定于实现的。
An explicit authorization identity assertion is accomplished after TLS establishment by invoking a Bind request of the SASL form using the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the credentials octet string. This string MUST be constructed as documented in section 9 of [AuthMeth].
TLS建立后，通过使用“外部”机制名称[SASL，LDAPv3]调用SASL表单的绑定请求来完成显式授权标识断言，该名称应包括凭证八位字节字符串。此字符串必须按照[AuthMeth]第9节中的说明构造。
For either form of assertion, the server MUST verify that the client's authentication identity as supplied in its TLS credentials is permitted to be mapped to the asserted authorization identity. The server MUST reject the Bind operation with an invalidCredentials resultCode in the Bind response if the client is not so authorized.
对于任何一种断言形式，服务器都必须验证其TLS凭据中提供的客户端身份验证标识是否允许映射到断言的授权标识。如果客户端未经授权，服务器必须在绑定响应中使用invalidCredentials resultCode拒绝绑定操作。
Additionally, with either form of assertion, 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 [IPSEC]), 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.
此外，无论采用哪种断言形式，如果在发出SASL外部绑定请求之前，客户机和服务器之间尚未建立TLS会话，并且没有其他外部身份验证凭据来源（例如，IP级别安全[IPSEC]），或者如果在建立TLS会话的过程中，服务器未请求客户端的身份验证凭据，SASL外部绑定必须失败，结果代码为身份验证不正确。
After the above Bind operation failures, any client authentication and authorization state of the LDAP association is lost, so the LDAP association is in an anonymous state after the failure. TLS connection state is unaffected, though a server MAY end the TLS connection, via a TLS close_notify message, based on the Bind failure (as it MAY at any time).
在上述绑定操作失败后，LDAP关联的任何客户端身份验证和授权状态都将丢失，因此失败后LDAP关联处于匿名状态。TLS连接状态不受影响，但服务器可以根据绑定失败（在任何时候）通过TLS close_notify消息结束TLS连接。
Closure of the TLS connection MUST cause the LDAP association to move to an anonymous authentication and authorization state regardless of the state established over TLS and regardless of the authentication and authorization state prior to TLS connection establishment.
关闭TLS连接必须导致LDAP关联移动到匿名身份验证和授权状态，而不管通过TLS建立的状态如何，也不管TLS连接建立之前的身份验证和授权状态如何。
The goals of using the TLS protocol with LDAP are to ensure connection confidentiality and integrity, and to optionally provide for authentication. TLS expressly provides these capabilities, as described in [TLS].
将TLS协议与LDAP结合使用的目的是确保连接的机密性和完整性，并可选地提供身份验证。TLS明确提供这些功能，如[TLS]中所述。
All security gained via use of the Start TLS operation is gained by the use of TLS itself. The Start TLS operation, on its own, does not provide any additional security.
通过使用Start TLS操作获得的所有安全性都是通过使用TLS本身获得的。启动TLS操作本身不提供任何额外的安全性。
The use of TLS does not provide or ensure for confidentiality and/or non-repudiation of the data housed by an LDAP-based directory server. Nor does it secure the data from inspection by the server administrators. Once established, TLS only provides for and ensures confidentiality and integrity of the operations and data in transit over the LDAP association, and only if the implementations on the client and server support and negotiate it.
TLS的使用不会提供或确保基于LDAP的目录服务器所包含数据的机密性和/或不可否认性。它也不能保护数据不被服务器管理员检查。一旦建立，TLS仅提供并确保通过LDAP关联传输的操作和数据的机密性和完整性，并且仅当客户端和服务器上的实现支持并协商时。
The level of security provided though the use of TLS depends directly on both the quality of the TLS implementation used and the style of usage of that implementation. Additionally, an active-intermediary attacker can remove the Start TLS extended operation from the supportedExtension attribute of the root DSE. Therefore, both parties SHOULD independently ascertain and consent to the security level achieved once TLS is established and before beginning use of the TLS connection. For example, the security level of the TLS connection might have been negotiated down to plaintext.
通过使用TLS提供的安全级别直接取决于所使用的TLS实现的质量和该实现的使用风格。此外，活动中间攻击者可以从根DSE的supportedExtension属性中删除Start TLS extended操作。因此，双方应在TLS建立后和开始使用TLS连接之前独立确定并同意达到的安全级别。例如，TLS连接的安全级别可能已协商为明文。
Clients SHOULD either warn the user when the security level achieved does not provide confidentiality and/or integrity protection, or be configurable to refuse to proceed without an acceptable level of security.
当达到的安全级别不提供机密性和/或完整性保护时，客户端应向用户发出警告，或者配置为在没有可接受的安全级别的情况下拒绝继续。
Client and server implementors SHOULD take measures to ensure proper protection of credentials and other confidential data where such measures are not otherwise provided by the TLS implementation.
客户机和服务器实施者应采取措施，确保适当保护TLS实施未另行提供的凭据和其他机密数据。
Server implementors SHOULD allow for server administrators to elect whether and when connection confidentiality and/or integrity is required, as well as elect whether and when client authentication via TLS is required.
服务器实现者应允许服务器管理员选择是否和何时需要连接机密性和/或完整性，以及选择是否和何时需要通过TLS进行客户端身份验证。
The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their contributions to this document.
作者感谢Tim Howes、Paul Hoffman、John Kristian、Shirish Rai、Jonathan Trostle、Harald Alvestrand和Marcus Leech对本文件的贡献。
[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[AuthMeth]Wahl，M.，Alvestrand，H.，Hodges，J.和R.Morgan，“LDAP的身份验证方法”，RFC 28292000年5月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAPv3]Wahl，M.，Kille S.和T.Howes，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[ReqsKeywords]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0", RFC 2246, January 1999.
迪克斯，T.和C.艾伦。“TLS协议1.0版”，RFC 2246，1999年1月。
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 USA
美国华盛顿大学西雅图分校摩根计算与通信
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
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
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
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编辑功能的资金目前由互联网协会提供。