Network Working Group R. Harrison, Ed.
Request for Comments: 4513 Novell, Inc.
Obsoletes: 2251, 2829, 2830 June 2006
Category: Standards Track
Network Working Group R. Harrison, Ed.
Request for Comments: 4513 Novell, Inc.
Obsoletes: 2251, 2829, 2830 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
轻量级目录访问协议（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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.
本文档描述了轻量级目录访问协议（LDAP）的身份验证方法和安全机制。本文档详细介绍了使用StartTLS操作建立传输层安全性（TLS）。
This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.
本文档详细介绍了简单绑定身份验证方法，包括匿名、未经验证和名称/密码机制，以及简单身份验证和安全层（SASL）绑定身份验证方法，包括外部机制。
This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.
本文档讨论LDAP服务器会话可能通过的各种身份验证和授权状态，以及触发这些状态更改的操作。
This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830.
本文件以及LDAP技术规范中的其他文件（见规范路线图第1节）废除了RFC 2251、RFC 2829和RFC 2830。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Relationship to Other Documents ............................6
1.2. Conventions ................................................6
2. Implementation Requirements .....................................7
3. StartTLS Operation ..............................................8
3.1. TLS Establishment Procedures ..............................8
3.1.1. StartTLS Request Sequencing .........................8
3.1.2. Client Certificate ..................................9
3.1.3. Server Identity Check ...............................9
3.1.3.1. Comparison of DNS Names ...................10
3.1.3.2. Comparison of IP Addresses ................11
3.1.3.3. Comparison of Other subjectName Types .....11
3.1.4. Discovery of Resultant Security Level ..............11
3.1.5. Refresh of Server Capabilities Information .........11
3.2. Effect of TLS on Authorization State .....................12
3.3. TLS Ciphersuites ..........................................12
4. Authorization State ............................................13
5. Bind Operation .................................................14
5.1. Simple Authentication Method ..............................14
5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
5.1.2. Unauthenticated Authentication Mechanism of
Simple Bind ........................................14
5.1.3. Name/Password Authentication Mechanism of
Simple Bind ........................................15
5.2. SASL Authentication Method ................................16
5.2.1. SASL Protocol Profile ..............................16
5.2.1.1. SASL Service Name for LDAP ................16
5.2.1.2. SASL Authentication Initiation and
Protocol Exchange .........................16
5.2.1.3. Optional Fields ...........................17
5.2.1.4. Octet Where Negotiated Security
Layers Take Effect ........................18
5.2.1.5. Determination of Supported SASL
Mechanisms ................................18
5.2.1.6. Rules for Using SASL Layers ...............19
5.2.1.7. Support for Multiple Authentications ......19
5.2.1.8. SASL Authorization Identities .............19
5.2.2. SASL Semantics within LDAP .........................20
5.2.3. SASL EXTERNAL Authentication Mechanism .............20
5.2.3.1. Implicit Assertion ........................21
5.2.3.2. Explicit Assertion ........................21
6. Security Considerations ........................................21
6.1. General LDAP Security Considerations ......................21
6.2. StartTLS Security Considerations ..........................22
6.3. Bind Operation Security Considerations ....................23
6.3.1. Unauthenticated Mechanism Security Considerations ..23
1. Introduction ....................................................4
1.1. Relationship to Other Documents ............................6
1.2. Conventions ................................................6
2. Implementation Requirements .....................................7
3. StartTLS Operation ..............................................8
3.1. TLS Establishment Procedures ..............................8
3.1.1. StartTLS Request Sequencing .........................8
3.1.2. Client Certificate ..................................9
3.1.3. Server Identity Check ...............................9
3.1.3.1. Comparison of DNS Names ...................10
3.1.3.2. Comparison of IP Addresses ................11
3.1.3.3. Comparison of Other subjectName Types .....11
3.1.4. Discovery of Resultant Security Level ..............11
3.1.5. Refresh of Server Capabilities Information .........11
3.2. Effect of TLS on Authorization State .....................12
3.3. TLS Ciphersuites ..........................................12
4. Authorization State ............................................13
5. Bind Operation .................................................14
5.1. Simple Authentication Method ..............................14
5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
5.1.2. Unauthenticated Authentication Mechanism of
Simple Bind ........................................14
5.1.3. Name/Password Authentication Mechanism of
Simple Bind ........................................15
5.2. SASL Authentication Method ................................16
5.2.1. SASL Protocol Profile ..............................16
5.2.1.1. SASL Service Name for LDAP ................16
5.2.1.2. SASL Authentication Initiation and
Protocol Exchange .........................16
5.2.1.3. Optional Fields ...........................17
5.2.1.4. Octet Where Negotiated Security
Layers Take Effect ........................18
5.2.1.5. Determination of Supported SASL
Mechanisms ................................18
5.2.1.6. Rules for Using SASL Layers ...............19
5.2.1.7. Support for Multiple Authentications ......19
5.2.1.8. SASL Authorization Identities .............19
5.2.2. SASL Semantics within LDAP .........................20
5.2.3. SASL EXTERNAL Authentication Mechanism .............20
5.2.3.1. Implicit Assertion ........................21
5.2.3.2. Explicit Assertion ........................21
6. Security Considerations ........................................21
6.1. General LDAP Security Considerations ......................21
6.2. StartTLS Security Considerations ..........................22
6.3. Bind Operation Security Considerations ....................23
6.3.1. Unauthenticated Mechanism Security Considerations ..23
6.3.2. Name/Password Mechanism Security Considerations ....23
6.3.3. Password-Related Security Considerations ...........23
6.3.4. Hashed Password Security Considerations ............24
6.4. SASL Security Considerations ..............................24
6.5. Related Security Considerations ...........................25
7. IANA Considerations ............................................25
8. Acknowledgements ...............................................25
9. Normative References ...........................................26
10. Informative References ........................................27
Appendix A. Authentication and Authorization Concepts .............28
A.1. Access Control Policy .....................................28
A.2. Access Control Factors ....................................28
A.3. Authentication, Credentials, Identity .....................28
A.4. Authorization Identity ....................................29
Appendix B. Summary of Changes ....................................29
B.1. Changes Made to RFC 2251 ..................................30
B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
B.1.2. Section 4.2.2 ("Authentication and Other Security
Services") .........................................30
B.2. Changes Made to RFC 2829 ..................................30
B.2.1. Section 4 ("Required security mechanisms") .........30
B.2.2. Section 5.1 ("Anonymous authentication
procedure") ........................................31
B.2.3. Section 6 ("Password-based authentication") ........31
B.2.4. Section 6.1 ("Digest authentication") ..............31
B.2.5. Section 6.2 ("'simple' authentication choice under
TLS encryption") ...................................31
B.2.6. Section 6.3 ("Other authentication choices with
TLS") ..............................................31
B.2.7. Section 7.1 ("Certificate-based authentication
with TLS") .........................................31
B.2.8. Section 8 ("Other mechanisms") .....................32
B.2.9. Section 9 ("Authorization Identity") ...............32
B.2.10. Section 10 ("TLS Ciphersuites") ...................32
B.3. Changes Made to RFC 2830 ..................................32
B.3.1. Section 3.6 ("Server Identity Check") ..............32
B.3.2. Section 3.7 ("Refresh of Server Capabilities
Information") ......................................33
B.3.3. Section 5 ("Effects of TLS on a Client's
Authorization Identity") ...........................33
B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
6.3.2. Name/Password Mechanism Security Considerations ....23
6.3.3. Password-Related Security Considerations ...........23
6.3.4. Hashed Password Security Considerations ............24
6.4. SASL Security Considerations ..............................24
6.5. Related Security Considerations ...........................25
7. IANA Considerations ............................................25
8. Acknowledgements ...............................................25
9. Normative References ...........................................26
10. Informative References ........................................27
Appendix A. Authentication and Authorization Concepts .............28
A.1. Access Control Policy .....................................28
A.2. Access Control Factors ....................................28
A.3. Authentication, Credentials, Identity .....................28
A.4. Authorization Identity ....................................29
Appendix B. Summary of Changes ....................................29
B.1. Changes Made to RFC 2251 ..................................30
B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
B.1.2. Section 4.2.2 ("Authentication and Other Security
Services") .........................................30
B.2. Changes Made to RFC 2829 ..................................30
B.2.1. Section 4 ("Required security mechanisms") .........30
B.2.2. Section 5.1 ("Anonymous authentication
procedure") ........................................31
B.2.3. Section 6 ("Password-based authentication") ........31
B.2.4. Section 6.1 ("Digest authentication") ..............31
B.2.5. Section 6.2 ("'simple' authentication choice under
TLS encryption") ...................................31
B.2.6. Section 6.3 ("Other authentication choices with
TLS") ..............................................31
B.2.7. Section 7.1 ("Certificate-based authentication
with TLS") .........................................31
B.2.8. Section 8 ("Other mechanisms") .....................32
B.2.9. Section 9 ("Authorization Identity") ...............32
B.2.10. Section 10 ("TLS Ciphersuites") ...................32
B.3. Changes Made to RFC 2830 ..................................32
B.3.1. Section 3.6 ("Server Identity Check") ..............32
B.3.2. Section 3.7 ("Refresh of Server Capabilities
Information") ......................................33
B.3.3. Section 5 ("Effects of TLS on a Client's
Authorization Identity") ...........................33
B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a powerful protocol for accessing directories. It offers means of searching, retrieving, and manipulating directory content and ways to access a rich set of security functions.
轻量级目录访问协议（LDAP）[RFC4510]是访问目录的强大协议。它提供了搜索、检索和操作目录内容的方法，以及访问一组丰富的安全功能的方法。
It is vital that these security functions be interoperable among all LDAP clients and servers on the Internet; therefore there has to be a minimum subset of security functions that is common to all implementations that claim LDAP conformance.
这些安全功能在Internet上的所有LDAP客户端和服务器之间具有互操作性是至关重要的；因此，必须有一个安全函数的最小子集，这是所有声明LDAP一致性的实现所共有的。
Basic threats to an LDAP directory service include (but are not limited to):
LDAP目录服务的基本威胁包括（但不限于）：
(1) Unauthorized access to directory data via data-retrieval operations.
(1) 通过数据检索操作对目录数据进行未经授权的访问。
(2) Unauthorized access to directory data by monitoring access of others.
(2) 通过监视其他人的访问来对目录数据进行未经授权的访问。
(3) Unauthorized access to reusable client authentication information by monitoring access of others.
(3) 通过监视其他人的访问来对可重用客户端身份验证信息进行未经授权的访问。
(4) Unauthorized modification of directory data.
(4) 未经授权修改目录数据。
(5) Unauthorized modification of configuration information.
(5) 未经授权修改配置信息。
(6) Denial of Service: Use of resources (commonly in excess) in a manner intended to deny service to others.
(6) 拒绝服务：以拒绝向他人提供服务的方式使用资源（通常过量）。
(7) Spoofing: Tricking a user or 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 transport connection. Tricking a user or client into sending privileged information to a hostile entity that appears to be the directory server but is not. Tricking a directory server into believing that information came from a particular client when in fact it came from a hostile entity.
(7) 欺骗：通过修改传输中的数据或错误引导客户端的传输连接，诱骗用户或客户端相信信息来自目录，而实际上并非如此。诱使用户或客户端向看似是目录服务器但不是的敌对实体发送特权信息。欺骗目录服务器，使其相信信息来自某个特定的客户机，而实际上它来自一个敌对实体。
(8) Hijacking: An attacker seizes control of an established protocol session.
(8) 劫持：攻击者夺取已建立协议会话的控制权。
Threats (1), (4), (5), (6), (7), and (8) are active attacks. Threats (2) and (3) are passive attacks.
威胁（1）、（4）、（5）、（6）、（7）和（8）是主动攻击。威胁（2）和（3）是被动攻击。
Threats (1), (4), (5), and (6) are due to hostile clients. Threats (2), (3), (7), and (8) are due to hostile agents on the path between client and server or hostile agents posing as a server, e.g., IP spoofing.
威胁（1）、（4）、（5）和（6）是由敌对客户造成的。威胁（2）、（3）、（7）和（8）是由于客户端和服务器之间路径上的敌对代理或伪装成服务器的敌对代理造成的，例如IP欺骗。
LDAP offers the following security mechanisms:
LDAP提供以下安全机制：
(1) Authentication by means of the Bind operation. The Bind operation provides a simple method that supports anonymous, unauthenticated, and name/password mechanisms, and the Simple Authentication and Security Layer (SASL) method, which supports a wide variety of authentication mechanisms.
(1) 通过绑定操作进行身份验证。绑定操作提供了一个支持匿名、未经身份验证和名称/密码机制的简单方法，以及支持多种身份验证机制的简单身份验证和安全层（SASL）方法。
(2) Mechanisms to support vendor-specific access control facilities (LDAP does not offer a standard access control facility).
(2) 支持特定于供应商的访问控制设施的机制（LDAP不提供标准的访问控制设施）。
(3) Data integrity service by means of security layers in Transport Layer Security (TLS) or SASL mechanisms.
(3) 通过传输层安全（TLS）或SASL机制中的安全层提供数据完整性服务。
(4) Data confidentiality service by means of security layers in TLS or SASL mechanisms.
(4) 通过TLS或SASL机制中的安全层提供数据保密服务。
(5) Server resource usage limitation by means of administrative limits configured on the server.
(5) 通过在服务器上配置的管理限制来限制服务器资源使用。
(6) Server authentication by means of the TLS protocol or SASL mechanisms.
(6) 通过TLS协议或SASL机制进行服务器身份验证。
LDAP may also be protected by means outside the LDAP protocol, e.g., with IP layer security [RFC4301].
LDAP也可以通过LDAP协议之外的方式进行保护，例如，使用IP层安全[RFC4301]。
Experience has shown that simply allowing implementations to pick and choose the security mechanisms that will be implemented is not a strategy that leads to interoperability. In the absence of mandates, clients will continue to be written that do not support any security function supported by the server, or worse, they will only support mechanisms that provide inadequate security for most circumstances.
经验表明，简单地允许实现选择将要实现的安全机制并不是一种导致互操作性的策略。在没有授权的情况下，将继续编写不支持服务器支持的任何安全功能的客户端，或者更糟糕的是，它们只支持在大多数情况下提供不充分安全性的机制。
It is desirable to allow clients to authenticate using a variety of mechanisms including mechanisms where identities are represented as distinguished names [X.501][RFC4512], in string form [RFC4514], or as used in different systems (e.g., simple user names [RFC4013]). Because some authentication mechanisms transmit credentials in plain text form, and/or do not provide data security services and/or are subject to passive attacks, it is necessary to ensure secure interoperability by identifying a mandatory-to-implement mechanism for establishing transport-layer security services.
希望允许客户端使用各种机制进行身份验证，包括将身份表示为可分辨名称[X.501][RFC4512]、字符串形式[RFC4514]或在不同系统中使用的机制（例如，简单用户名[RFC4013]）。由于某些身份验证机制以纯文本形式传输凭据，和/或不提供数据安全服务和/或受到被动攻击，因此有必要通过确定用于建立传输层安全服务的强制实施机制来确保安全互操作性。
The set of security mechanisms provided in LDAP and described in this document is intended to meet the security needs for a wide range of deployment scenarios and still provide a high degree of interoperability among various LDAP implementations and deployments.
LDAP中提供并在本文档中描述的一组安全机制旨在满足各种部署场景的安全需求，并在各种LDAP实现和部署之间提供高度的互操作性。
This document is an integral part of the LDAP Technical Specification [RFC4510].
本文档是LDAP技术规范[RFC4510]的组成部分。
This document, together with [RFC4510], [RFC4511], and [RFC4512], obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions) and 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1 summarizes the substantive changes made to RFC 2251 by this document.
本文件连同[RFC4510]、[RFC4511]和[RFC4512]完全废弃了RFC 2251。RFC 2251第4.2.1节（部分）和第4.2.2节已被本文件废除。附录B.1总结了本文件对RFC 2251所做的实质性更改。
This document obsoletes RFC 2829 in its entirety. Appendix B.2 summarizes the substantive changes made to RFC 2829 by this document.
本文件完全废除了RFC 2829。附录B.2总结了本文件对RFC 2829所做的实质性更改。
Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511]. The remainder of RFC 2830 is obsoleted by this document. Appendix B.3 summarizes the substantive changes made to RFC 2830 by this document.
[RFC4511]废除了RFC 2830第2节和第4节。RFC 2830的其余部分已被本文件淘汰。附录B.3总结了本文件对RFC 2830所做的实质性更改。
The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“应”、“应”、“不应”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
The term "user" represents any human or application entity that is accessing the directory using a directory client. A directory client (or client) is also known as a directory user agent (DUA).
术语“用户”表示使用目录客户端访问目录的任何人员或应用程序实体。目录客户端（或客户端）也称为目录用户代理（DUA）。
The term "transport connection" refers to the underlying transport services used to carry the protocol exchange, as well as associations established by these services.
术语“传输连接”指用于承载协议交换的底层传输服务，以及由这些服务建立的关联。
The term "TLS layer" refers to TLS services used in providing security services, as well as associations established by these services.
术语“TLS层”指用于提供安全服务的TLS服务，以及由这些服务建立的关联。
The term "SASL layer" refers to SASL services used in providing security services, as well as associations established by these services.
术语“SASL层”指用于提供安全服务的SASL服务，以及由这些服务建立的关联。
The term "LDAP message layer" refers to the LDAP Message (PDU) services used in providing directory services, as well as associations established by these services.
术语“LDAP消息层”指用于提供目录服务的LDAP消息（PDU）服务，以及由这些服务建立的关联。
The term "LDAP session" refers to combined services (transport connection, TLS layer, SASL layer, LDAP message layer) and their associations.
术语“LDAP会话”是指组合服务（传输连接、TLS层、SASL层、LDAP消息层）及其关联。
In general, security terms in this document are used consistently with the definitions provided in [RFC2828]. In addition, several terms and concepts relating to security, authentication, and authorization are presented in Appendix A of this document. While the formal definition of these terms and concepts is outside the scope of this document, an understanding of them is prerequisite to understanding much of the material in this document. Readers who are unfamiliar with security-related concepts are encouraged to review Appendix A before reading the remainder of this document.
一般而言，本文件中的安全术语与[RFC2828]中提供的定义一致。此外，本文件附录A中还介绍了与安全性、身份验证和授权相关的几个术语和概念。虽然这些术语和概念的正式定义不在本文件范围内，但理解它们是理解本文件大部分内容的先决条件。鼓励不熟悉安全相关概念的读者在阅读本文档的其余部分之前先阅读附录A。
LDAP server implementations MUST support the anonymous authentication mechanism of the simple Bind method (Section 5.1.1).
LDAP服务器实现必须支持简单绑定方法的匿名身份验证机制（第5.1.1节）。
LDAP implementations that support any authentication mechanism other than the anonymous authentication mechanism of the simple Bind method MUST support the name/password authentication mechanism of the simple Bind method (Section 5.1.3) and MUST be capable of protecting this name/password authentication using TLS as established by the StartTLS operation (Section 3).
支持除简单绑定方法的匿名身份验证机制以外的任何身份验证机制的LDAP实现必须支持简单绑定方法的名称/密码身份验证机制（第5.1.3节）并且必须能够使用StartTLS操作（第3节）建立的TLS保护此名称/密码身份验证。
Implementations SHOULD disallow the use of the name/password authentication mechanism by default when suitable data security services are not in place, and they MAY provide other suitable data security services for use with this authentication mechanism.
当合适的数据安全服务未到位时，默认情况下，实现应禁止使用名称/密码身份验证机制，并且它们可以提供其他合适的数据安全服务以与此身份验证机制一起使用。
Implementations MAY support additional authentication mechanisms. Some of these mechanisms are discussed below.
实现可能支持额外的身份验证机制。下面将讨论其中一些机制。
LDAP server implementations SHOULD support client assertion of authorization identity via the SASL EXTERNAL mechanism (Section 5.2.3).
LDAP服务器实现应支持通过SASL外部机制（第5.2.3节）对授权标识的客户端断言。
LDAP server implementations that support no authentication mechanism other than the anonymous mechanism of the simple bind method SHOULD support use of TLS as established by the StartTLS operation (Section 3). (Other servers MUST support TLS per the second paragraph of this section.)
除了简单绑定方法的匿名机制之外，不支持任何身份验证机制的LDAP服务器实现应该支持使用由StartTLS操作建立的TLS（第3节）。（根据本节第二段，其他服务器必须支持TLS。）
Implementations supporting TLS MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the latter ciphersuite is recommended to encourage interoperability with implementations conforming to earlier LDAP StartTLS specifications.
支持TLS的实施必须支持TLS、RSA和CBC、SHA密码套件，并应支持TLS、DSS和CBC、SHA密码套件。建议支持后一种密码套件，以鼓励与符合早期LDAP StartTLS规范的实现的互操作性。
The Start Transport Layer Security (StartTLS) operation defined in Section 4.14 of [RFC4511] provides the ability to establish TLS [RFC4346] in an LDAP session.
[RFC4511]第4.14节中定义的启动传输层安全（StartTLS）操作提供了在LDAP会话中建立TLS[RFC4346]的能力。
The goals of using the TLS protocol with LDAP are to ensure data confidentiality and integrity, and to optionally provide for authentication. TLS expressly provides these capabilities, although the authentication services of TLS are available to LDAP only in combination with the SASL EXTERNAL authentication method (see Section 5.2.3), and then only if the SASL EXTERNAL implementation chooses to make use of the TLS credentials.
将TLS协议与LDAP结合使用的目标是确保数据的机密性和完整性，并可选地提供身份验证。TLS明确地提供了这些功能，尽管TLS的身份验证服务仅在与SASL外部身份验证方法结合使用时（参见第5.2.3节）才对LDAP可用，并且只有在SASL外部实现选择使用TLS凭据时才可用。
This section describes the overall procedures clients and servers must follow for TLS establishment. These procedures take into consideration various aspects of the TLS layer including discovery of resultant security level and assertion of the client's authorization identity.
本节描述了客户机和服务器建立TLS必须遵循的总体程序。这些过程考虑了TLS层的各个方面，包括结果安全级别的发现和客户端授权标识的断言。
A client may send the StartTLS extended request at any time after establishing an LDAP session, except:
客户端可以在建立LDAP会话后的任何时间发送StartTLS扩展请求，但以下情况除外：
- when TLS is currently established on the session, - when a multi-stage SASL negotiation is in progress on the session, or - when there are outstanding responses for operation requests previously issued on the session.
- 当前在会话上建立TLS时，-会话上正在进行多阶段SASL协商时，或-会话上先前发出的操作请求有未完成响应时。
As described in [RFC4511], Section 4.14.1, a (detected) violation of any of these requirements results in a return of the operationsError resultCode.
如[RFC4511]第4.14.1节所述，（检测到）违反任何这些要求将导致返回operationsError resultCode。
Client implementers should ensure that they strictly follow these operation sequencing requirements to prevent interoperability issues. Operational experience has shown that violating these requirements
客户机实现者应确保严格遵守这些操作顺序要求，以防止互操作性问题。运行经验表明，违反这些要求
causes interoperability issues because there are race conditions that prevent servers from detecting some violations of these requirements due to factors such as server hardware speed and network latencies.
导致互操作性问题，因为存在竞争条件，这些竞争条件会阻止服务器检测到由于服务器硬件速度和网络延迟等因素而违反这些要求的行为。
There is no general requirement that the client have or have not already performed a Bind operation (Section 5) before sending a StartTLS operation request; however, where a client intends to perform both a Bind operation and a StartTLS operation, it SHOULD first perform the StartTLS operation so that the Bind request and response messages are protected by the data security services established by the StartTLS operation.
在发送StartTLS操作请求之前，客户没有或没有执行绑定操作（第5节）的一般要求；但是，如果客户机打算同时执行绑定操作和StartTLS操作，则应首先执行StartTLS操作，以便绑定请求和响应消息受到StartTLS操作建立的数据安全服务的保护。
If an LDAP server requests or demands that a client provide a user certificate during TLS negotiation and the client does not present a suitable user certificate (e.g., one that can be validated), the server may use a local security policy to determine whether to successfully complete TLS negotiation.
如果LDAP服务器在TLS协商期间请求或要求客户端提供用户证书，而客户端没有提供合适的用户证书（例如，可以验证的证书），则服务器可以使用本地安全策略来确定是否成功完成TLS协商。
If a client that has provided a suitable certificate subsequently performs a Bind operation using the SASL EXTERNAL authentication mechanism (Section 5.2.3), information in the certificate may be used by the server to identify and authenticate the client.
如果提供了适当证书的客户端随后使用SASL外部身份验证机制（第5.2.3节）执行绑定操作，则服务器可以使用证书中的信息来识别和验证客户端。
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). In this section, the client's understanding of the server's identity (typically the identity used to establish the transport connection) is called the "reference identity".
为了防止中间人攻击，客户端必须验证服务器的身份（如服务器的证书消息中所示）。在本节中，客户端对服务器标识（通常是用于建立传输连接的标识）的理解称为“参考标识”。
The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of various subjectAltName types.
客户端确定参考标识的类型（例如DNS名称或IP地址），并在参考标识和相应类型的每个subjectAltName值之间执行比较，直到生成匹配。一旦生成匹配项，服务器的标识就已验证，并且服务器标识检查已完成。不同的subjectAltName类型以不同的方式匹配。第3.1.3.1-3.1.3.3节解释了如何比较各种subjectAltName类型的值。
The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped; however, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName
客户端可以在执行比较之前将参考标识映射到不同的类型。可以对引用标识可以映射到的所有可用subjectAltName类型执行映射；但是，引用标识应仅映射到映射本身安全的类型（例如，从URI提取DNS名称以与subjectAltName进行比较）
of type dNSName) or for which the mapping is performed in a secure manner (e.g., using DNSSEC, or using user- or admin-configured host-to-address/address-to-host lookup tables).
dNSName类型）或以安全方式执行映射（例如，使用DNSSEC，或使用用户或管理员配置的主机到地址/主机到地址查找表）。
The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention.
还可以通过将参考标识与服务器证书的subjectName字段的叶相对可分辨名称（RDN）中的公共名称（CN）[RFC4519]值进行比较来验证服务器的标识。此比较使用下面第3.1.3.1节中的DNS名称比较规则执行，但不允许通配符匹配。虽然公共名称值的使用是现有的做法，但不推荐使用，并鼓励证书颁发机构提供subjectAltName值。注意，TLS实现可以根据X.500或其他约定在证书中表示DNs。例如，一些X.500实现使用从左到右（最重要到最不重要）约定而不是LDAP的从右到左约定对DN中的RDN进行排序。
If the server identity check fails, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect or both.
如果服务器标识检查失败，面向用户的客户端应该通知用户（在这种情况下，客户端可能会给用户继续LDAP会话的机会），或者关闭传输连接并指示服务器标识可疑。自动客户端应关闭传输连接，然后返回或记录一个错误，表明服务器的身份可疑或两者兼有。
Beyond the server identity check 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 requested to provide. The client may need to make use of local policy information in making this determination.
除了本节中描述的服务器身份检查之外，客户机还应该准备进行进一步的检查，以确保服务器有权提供请求提供的服务。客户可能需要利用当地的政策信息来确定。
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of RFC 3490 as follows:
如果参考标识是国际化域名，则在与dNSName类型的subjectAltName值进行比较之前，一致性实现必须将其转换为RFC 3490[RFC3490]第4节中规定的ASCII兼容编码（ACE）格式。具体而言，符合性实施必须执行RFC 3490第4节规定的转换操作，如下所示：
* in step 1, the domain name SHALL be considered a "stored string"; * in step 3, set the flag called "UseSTD3ASCIIRules"; * in step 4, process each label with the "ToASCII" operation; and * in step 5, change all label separators to U+002E (full stop).
* 在步骤1中，域名应被视为“存储字符串”*在步骤3中，设置名为“usestd3ascirules”的标志*在步骤4中，使用“ToASCII”操作处理每个标签；和*在步骤5中，将所有标签分隔符更改为U+002E（句号）。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of RFC3490.
执行“到ASCII”转换后，必须根据RFC3490第3节中规定的规则比较DNS标签和名称是否相等。
The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
dNSName类型的subjectAltName值中允许使用“*”（ASCII 42）通配符，然后仅作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.example.com与服务器名a.example.com和b.example.com匹配，但与example.com或a.b.example.com不匹配。
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP Version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
当参考标识是IP地址时，该标识必须转换为“网络字节顺序”八位字节字符串表示形式[RFC791][RFC2460]。对于IP版本4，如RFC 791中所述，八位字节字符串将正好包含四个八位字节。对于IP版本6，如RFC 2460中所规定，八位字节字符串将正好包含十六个八位字节。然后将此八位组字符串与iPAddress类型的subjectAltName值进行比较。如果引用标识八位字节字符串和值八位字节字符串相同，则会发生匹配。
Client implementations MAY support matching against subjectAltName values of other types as described in other documents.
客户端实现可能支持与其他文档中描述的其他类型的subjectAltName值进行匹配。
After a TLS layer is established in an LDAP session, both parties are to each independently decide whether or not to continue based on local policy and the security level achieved. If either party decides that the security level is inadequate for it to continue, it SHOULD remove the TLS layer immediately after the TLS (re)negotiation has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below). Implementations may reevaluate the security level at any time and, upon finding it inadequate, should remove the TLS layer.
在LDAP会话中建立TLS层后，双方将各自根据本地策略和达到的安全级别独立决定是否继续。如果任何一方认为安全级别不足以继续，则应在TLS（重新）协商完成后立即移除TLS层（见下文[RFC4511]，第4.14.3节和第3.2节）。实现可能会在任何时候重新评估安全级别，并且在发现安全级别不足时，应该删除TLS层。
After a TLS layer is established in an LDAP session, the client SHOULD discard or refresh all information about the server that it obtained prior to the initiation of the TLS negotiation and that it did not obtain through secure mechanisms. This protects against man-in-the-middle attacks that may have altered any server capabilities information retrieved prior to TLS layer installation.
在LDAP会话中建立TLS层后，客户机应放弃或刷新在启动TLS协商之前获得的且未通过安全机制获得的有关服务器的所有信息。这可以防止中间人攻击，中间人攻击可能会改变TLS层安装之前检索到的任何服务器功能信息。
The server may advertise different capabilities after installing a TLS layer. In particular, the value of 'supportedSASLMechanisms' may be different after a TLS layer has been installed (specifically, the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only after a TLS layer has been installed).
安装TLS层后，服务器可能会公布不同的功能。特别是，安装TLS层后，“supportedSASLMechanisms”的值可能不同（具体而言，外部和普通[普通]机制可能仅在安装TLS层后列出）。
The establishment, change, and/or closure of TLS may cause the authorization state to move to a new state. This is discussed further in Section 4.
TLS的建立、更改和/或关闭可能会导致授权状态转移到新状态。这将在第4节中进一步讨论。
Several issues should be considered when selecting TLS ciphersuites that are appropriate for use in a given circumstance. These issues include the following:
在选择适用于特定环境的TLS密码套件时，应考虑几个问题。这些问题包括：
- The ciphersuite's ability to provide adequate confidentiality protection for passwords and other data sent over the transport connection. Client and server implementers should recognize that some TLS ciphersuites provide no confidentiality protection, while other ciphersuites that do provide confidentiality protection may be vulnerable to being cracked using brute force methods, especially in light of ever-increasing CPU speeds that reduce the time needed to successfully mount such attacks.
- 密码套件能够为通过传输连接发送的密码和其他数据提供充分的保密保护。客户机和服务器实现者应认识到，某些TLS密码套件不提供保密保护，而其他提供保密保护的密码套件可能容易被暴力破解，特别是考虑到CPU速度不断提高，从而缩短了成功实施此类攻击所需的时间。
- Client and server implementers should carefully consider the value of the password or data being protected versus the level of confidentiality protection provided by the ciphersuite to ensure that the level of protection afforded by the ciphersuite is appropriate.
- 客户端和服务器实现者应该仔细考虑密码或数据的保护值，而不是密码组提供的机密保护级别，以确保密码组提供的保护级别是合适的。
- The ciphersuite's vulnerability (or lack thereof) to man-in-the-middle attacks. Ciphersuites vulnerable to man-in-the-middle attacks 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 negligible.
- 密码套件对中间人攻击的脆弱性（或缺乏脆弱性）。易受中间人攻击的密码套件不应用于保护密码或敏感数据，除非网络配置使得中间人攻击的危险可以忽略不计。
- After a TLS negotiation (either initial or subsequent) is completed, both protocol peers should independently verify that the security services provided by the negotiated ciphersuite are adequate for the intended use of the LDAP session. If they are not, the TLS layer should be closed.
- TLS协商（初始协商或后续协商）完成后，两个协议对等方应独立验证协商的密码套件提供的安全服务是否足以满足LDAP会话的预期用途。如果没有，则应关闭TLS层。
Every LDAP session has an associated authorization state. This state is comprised of numerous factors such as what (if any) authentication state has been established, how it was established, and what security services are in place. Some factors may be determined and/or affected by protocol events (e.g., Bind, StartTLS, or TLS closure), and some factors may be determined by external events (e.g., time of day or server load).
每个LDAP会话都有一个关联的授权状态。此状态由许多因素组成，例如已建立了什么（如果有的话）身份验证状态、如何建立身份验证状态以及存在哪些安全服务。一些因素可能由协议事件（如Bind、StartTLS或TLS关闭）确定和/或影响，而一些因素可能由外部事件（如时间或服务器负载）确定。
While it is often convenient to view authorization state in simplistic terms (as we often do in this technical specification) such as "an anonymous state", it is noted that authorization systems in LDAP implementations commonly involve many factors that interrelate in complex manners.
虽然用过于简单的术语（正如我们在本技术规范中经常做的那样）查看授权状态（如“匿名状态”）通常很方便，但需要注意的是，LDAP实现中的授权系统通常涉及许多以复杂方式相互关联的因素。
Authorization in LDAP is a local matter. One of the key factors in making authorization decisions is authorization identity. The Bind operation (defined in Section 4.2 of [RFC4511] and discussed further in Section 5 below) allows information to be exchanged between the client and server to establish an authorization identity for the LDAP session. The Bind operation may also be used to move the LDAP session to an anonymous authorization state (see Section 5.1.1).
LDAP中的授权是本地事务。做出授权决策的关键因素之一是授权标识。绑定操作（在[RFC4511]的第4.2节中定义，并在下面的第5节中进一步讨论）允许在客户端和服务器之间交换信息，以建立LDAP会话的授权标识。绑定操作还可用于将LDAP会话移动到匿名授权状态（请参阅第5.1.1节）。
Upon initial establishment of the LDAP session, the session has an anonymous authorization identity. Among other things this implies that the client need not send a BindRequest in the first PDU of the LDAP message layer. The client may send any operation request prior to performing a Bind operation, and the server MUST treat it as if it had been performed after an anonymous Bind operation (Section 5.1.1).
初始建立LDAP会话时，会话具有匿名授权标识。这意味着客户端不需要在LDAP消息层的第一个PDU中发送BindRequest。客户端可以在执行绑定操作之前发送任何操作请求，服务器必须将其视为是在匿名绑定操作之后执行的（第5.1.1节）。
Upon receipt of a Bind request, the server immediately moves the session to an anonymous authorization state. If the Bind request is successful, the session is moved to the requested authentication state with its associated authorization state. Otherwise, the session remains in an anonymous state.
收到绑定请求后，服务器立即将会话移动到匿名授权状态。如果绑定请求成功，会话将移动到请求的身份验证状态及其关联的授权状态。否则，会话将保持匿名状态。
It is noted that other events both internal and external to LDAP may result in the authentication and authorization states being moved to an anonymous one. For instance, the establishment, change, or closure of data security services may result in a move to an anonymous state, or the user's credential information (e.g., certificate) may have expired. The former is an example of an event internal to LDAP, whereas the latter is an example of an event external to LDAP.
注意，LDAP内部和外部的其他事件可能会导致身份验证和授权状态移动到匿名状态。例如，数据安全服务的建立、更改或关闭可能导致移动到匿名状态，或者用户的凭证信息（例如，证书）可能已过期。前者是LDAP内部事件的示例，而后者是LDAP外部事件的示例。
The Bind operation ([RFC4511], Section 4.2) allows authentication information to be exchanged between the client and server to establish a new authorization state.
绑定操作（[RFC4511]，第4.2节）允许在客户端和服务器之间交换身份验证信息，以建立新的授权状态。
The Bind request typically specifies the desired authentication identity. Some Bind mechanisms also allow the client to specify the authorization identity. If the authorization identity is not specified, the server derives it from the authentication identity in an implementation-specific manner.
绑定请求通常指定所需的身份验证标识。一些绑定机制还允许客户端指定授权标识。如果未指定授权标识，服务器将以特定于实现的方式从身份验证标识派生授权标识。
If the authorization identity is specified, the server MUST verify that the client's authentication identity is permitted to assume (e.g., proxy for) 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.
如果指定了授权标识，服务器必须验证是否允许客户端的身份验证标识采用（例如代理）断言的授权标识。如果客户端未经授权，服务器必须在绑定响应中使用invalidCredentials resultCode拒绝绑定操作。
The simple authentication method of the Bind Operation provides three authentication mechanisms:
绑定操作的简单身份验证方法提供了三种身份验证机制：
- An anonymous authentication mechanism (Section 5.1.1).
- 匿名身份验证机制（第5.1.1节）。
- An unauthenticated authentication mechanism (Section 5.1.2).
- 未经验证的认证机制（第5.1.2节）。
- A name/password authentication mechanism using credentials consisting of a name (in the form of an LDAP distinguished name [RFC4514]) and a password (Section 5.1.3).
- 使用由名称（以LDAP可分辨名称[RFC4514]的形式）和密码（第5.1.3节）组成的凭据的名称/密码身份验证机制。
An LDAP client may use the anonymous authentication mechanism of the simple Bind method to explicitly establish an anonymous authorization state by sending a Bind request with a name value of zero length and specifying the simple authentication choice containing a password value of zero length.
LDAP客户端可以使用简单绑定方法的匿名身份验证机制，通过发送名称值为零的绑定请求并指定包含密码值为零的简单身份验证选项，显式建立匿名授权状态。
An LDAP client may use the unauthenticated authentication mechanism of the simple Bind method to establish an anonymous authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and specifying the simple authentication choice containing a password value of zero length.
LDAP客户端可以使用简单绑定方法的未经验证的身份验证机制，通过发送具有名称值（非零长度的LDAP字符串形式[RFC4514]中的可分辨名称）的绑定请求，并指定包含零长度密码值的简单身份验证选项，来建立匿名授权状态。
The distinguished name value provided by the client is intended to be used for trace (e.g., logging) purposes only. The value is not to be authenticated or otherwise validated (including verification that the DN refers to an existing directory object). The value is not to be used (directly or indirectly) for authorization purposes.
客户端提供的可分辨名称值仅用于跟踪（如日志记录）目的。不验证或以其他方式验证该值（包括验证DN是否引用现有目录对象）。该值不得（直接或间接）用于授权目的。
Unauthenticated Bind operations can have significant security issues (see Section 6.3.1). In particular, users intending to perform Name/Password Authentication may inadvertently provide an empty password and thus cause poorly implemented clients to request Unauthenticated access. Clients SHOULD be implemented to require user selection of the Unauthenticated Authentication Mechanism by means other than user input of an empty password. Clients SHOULD disallow an empty password input to a Name/Password Authentication user interface. Additionally, Servers SHOULD by default fail Unauthenticated Bind requests with a resultCode of unwillingToPerform.
未经验证的绑定操作可能存在重大安全问题（见第6.3.1节）。特别是，打算执行名称/密码身份验证的用户可能会无意中提供空密码，从而导致实现不佳的客户端请求未经身份验证的访问。应实现客户端，以要求用户通过用户输入空密码以外的方式选择未经验证的身份验证机制。客户端应禁止向名称/密码身份验证用户界面输入空密码。此外，默认情况下，服务器应使未经验证的绑定请求失败，结果代码为unwillingToPerform。
An LDAP client may use the name/password authentication mechanism of the simple Bind method to establish an authenticated authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and specifying the simple authentication choice containing an OCTET STRING password value of non-zero length.
LDAP客户端可以使用简单绑定方法的名称/密码身份验证机制，通过发送具有名称值（长度非零的LDAP字符串形式[RFC4514]的可分辨名称）的绑定请求来建立经过身份验证的授权状态以及指定包含长度非零的八位字节字符串密码值的简单身份验证选项。
Servers that map the DN sent in the Bind request to a directory entry with an associated set of one or more passwords used with this mechanism will compare the presented password to that set of passwords. The presented password is considered valid if it matches any member of this set.
将绑定请求中发送的DN映射到具有与此机制一起使用的一个或多个密码的关联集的目录条目的服务器将比较显示的密码与该密码集。如果提供的密码与此集合的任何成员匹配，则认为该密码有效。
A resultCode of invalidDNSyntax indicates that the DN sent in the name value is syntactically invalid. A resultCode of invalidCredentials indicates that the DN is syntactically correct but not valid for purposes of authentication, that the password is not valid for the DN, or that the server otherwise considers the credentials invalid. A resultCode of success indicates that the credentials are valid and that the server is willing to provide service to the entity these credentials identify.
invalidDNSyntax的resultCode表示在name值中发送的DN在语法上无效。invalidCredentials的resultCode表示DN语法正确，但出于身份验证目的无效，密码对DN无效，或者服务器认为凭据无效。resultCode成功表示凭据有效，并且服务器愿意向这些凭据标识的实体提供服务。
Server behavior is undefined for Bind requests specifying the name/password authentication mechanism with a zero-length name value and a password value of non-zero length.
对于使用零长度名称值和非零长度密码值指定名称/密码身份验证机制的绑定请求，服务器行为未定义。
The name/password authentication mechanism of the simple Bind method is not suitable for authentication in environments without confidentiality protection.
简单绑定方法的名称/密码身份验证机制不适合在没有保密保护的环境中进行身份验证。
The sasl authentication method of the Bind Operation provides facilities for using any SASL mechanism including authentication mechanisms and other services (e.g., data security services).
绑定操作的sasl身份验证方法提供了使用任何sasl机制的工具，包括身份验证机制和其他服务（例如，数据安全服务）。
LDAP allows authentication via any SASL mechanism [RFC4422]. As LDAP includes native anonymous and name/password (plain text) authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN] SASL mechanisms are typically not used with LDAP.
LDAP允许通过任何SASL机制进行身份验证[RFC4422]。由于LDAP包括本机匿名和名称/密码（纯文本）身份验证方法，因此匿名[RFC4505]和普通[plain]SASL机制通常不用于LDAP。
Each protocol that utilizes SASL services is required to supply certain information profiling the way they are exposed through the protocol ([RFC4422], Section 4). This section explains how each of these profiling requirements is met by LDAP.
每个利用SASL服务的协议都需要提供特定的信息，这些信息通过协议公开（[RFC4422]，第4节）。本节介绍LDAP如何满足这些评测需求。
The SASL service name for LDAP is "ldap", which has been registered with the IANA as a SASL service name.
LDAP的SASL服务名称是“LDAP”，它已作为SASL服务名称在IANA注册。
SASL authentication is initiated via a BindRequest message ([RFC4511], Section 4.2) with the following parameters:
SASL身份验证通过具有以下参数的BindRequest消息（[RFC4511]，第4.2节）启动：
- The version is 3. - The AuthenticationChoice is sasl. - The mechanism element of the SaslCredentials sequence contains the value of the desired SASL mechanism. - The optional credentials field of the SaslCredentials sequence MAY be used to provide an initial client response for mechanisms that are defined to have the client send data first (see [RFC4422], Sections 3 and 5).
- 版本是3AuthenticationChoice是sasl。-SaslCredentials序列的机制元素包含所需SASL机制的值。-SaslCredentials序列的可选凭证字段可用于为定义为让客户机首先发送数据的机制提供初始客户机响应（请参阅[RFC4422]，第3节和第5节）。
In general, a SASL authentication protocol exchange consists of a series of server challenges and client responses, the contents of which are specific to and defined by the SASL mechanism. Thus, for some SASL authentication mechanisms, it may be necessary for the client to respond to one or more server challenges by sending BindRequest messages multiple times. A challenge is indicated by the server sending a BindResponse message with the resultCode set to
通常，SASL身份验证协议交换由一系列服务器质询和客户端响应组成，其内容特定于SASL机制并由其定义。因此，对于某些SASL身份验证机制，客户端可能需要通过多次发送BindRequest消息来响应一个或多个服务器挑战。质询由服务器发送一条BindResponse消息（resultCode设置为）表示
saslBindInProgress. This indicates that the server requires the client to send a new BindRequest message with the same SASL mechanism to continue the authentication process.
saslBindInProgress。这表示服务器要求客户端使用相同的SASL机制发送新的BindRequest消息，以继续身份验证过程。
To the LDAP message layer, these challenges and responses are opaque binary tokens of arbitrary length. LDAP servers use the serverSaslCreds field (an OCTET STRING) in a BindResponse message to transmit each challenge. LDAP clients use the credentials field (an OCTET STRING) in the SaslCredentials sequence of a BindRequest message to transmit each response. Note that unlike some Internet protocols where SASL is used, LDAP is not text based and does not Base64-transform these challenge and response values.
对于LDAP消息层，这些挑战和响应是任意长度的不透明二进制令牌。LDAP服务器使用BindResponse消息中的ServersAllCreds字段（八位字符串）来传输每个质询。LDAP客户端使用BindRequest消息的SaslCredentials序列中的credentials字段（八位字符串）来传输每个响应。请注意，与使用SASL的某些Internet协议不同，LDAP不是基于文本的，并且不转换这些质询和响应值。
Clients sending a BindRequest message with the sasl choice selected SHOULD send a zero-length value in the name field. Servers receiving a BindRequest message with the sasl choice selected SHALL ignore any value in the name field.
选择sasl选项发送BindRequest消息的客户端应在名称字段中发送零长度值。接收选择了sasl选项的BindRequest消息的服务器应忽略名称字段中的任何值。
A client may abort a SASL Bind negotiation by sending a BindRequest message with a different value in the mechanism field of SaslCredentials or with an AuthenticationChoice other than sasl.
客户端可以通过在SaslCredentials的mechanism字段中发送具有不同值的BindRequest消息，或者使用除SASL之外的AuthenticationChoice来中止SASL绑定协商。
If the client sends a BindRequest with the sasl mechanism field as an empty string, the server MUST return a BindResponse with a resultCode of authMethodNotSupported. This will allow the client to abort a negotiation if it wishes to try again with the same SASL mechanism.
如果客户端以空字符串的形式发送带有sasl机制字段的BindRequest，则服务器必须返回一个结果代码为authMethodNotSupported的BindResponse。这将允许客户端在希望使用相同的SASL机制重试时中止协商。
The server indicates completion of the SASL challenge-response exchange by responding with a BindResponse in which the resultCode value is not saslBindInProgress.
服务器通过使用resultCode值不是saslBindInProgress的BindResponse进行响应来指示SASL质询响应交换的完成。
The serverSaslCreds field in the BindResponse can be used to include an optional challenge with a success notification for mechanisms that are defined to have the server send additional data along with the indication of successful completion.
BindResponse中的ServersAllCreds字段可用于包含一个可选的质询，该质询带有一个成功通知，该机制被定义为让服务器发送附加数据并指示成功完成。
As discussed above, LDAP provides an optional field for carrying an initial response in the message initiating the SASL exchange and provides an optional field for carrying additional data in the message indicating the outcome of the authentication exchange. As the mechanism-specific content in these fields may be zero length, SASL requires protocol specifications to detail how an empty field is distinguished from an absent field.
如上所述，LDAP提供了一个可选字段，用于在发起SASL交换的消息中承载初始响应，并提供了一个可选字段，用于在消息中承载指示身份验证交换结果的附加数据。由于这些字段中特定于机制的内容可能为零长度，SASL需要协议规范来详细说明如何区分空字段和空字段。
Zero-length initial response data is distinguished from no initial response data in the initiating message, a BindRequest PDU, by the presence of the SaslCredentials.credentials OCTET STRING (of length zero) in that PDU. If the client does not intend to send an initial response with the BindRequest initiating the SASL exchange, it MUST omit the SaslCredentials.credentials OCTET STRING (rather than include an zero-length OCTET STRING).
零长度初始响应数据与初始消息（BindRequest PDU）中的无初始响应数据的区别在于该PDU中存在SaslCredentials.credentials八位组字符串（长度为零）。如果客户机不打算在BindRequest启动SASL交换时发送初始响应，则必须省略SaslCredentials.credentials八位元字符串（而不是包含零长度八位元字符串）。
Zero-length additional data is distinguished from no additional response data in the outcome message, a BindResponse PDU, by the presence of the serverSaslCreds OCTET STRING (of length zero) in that PDU. If a server does not intend to send additional data in the BindResponse message indicating outcome of the exchange, the server SHALL omit the serverSaslCreds OCTET STRING (rather than including a zero-length OCTET STRING).
长度为零的附加数据与结果消息（BindResponse PDU）中没有附加响应数据的区别在于该PDU中存在ServersAllCreds八位字节字符串（长度为零）。如果服务器不打算在指示交换结果的BindResponse消息中发送额外数据，则服务器应省略ServersAllCreds八位字节字符串（而不是包含零长度八位字节字符串）。
SASL layers take effect following the transmission by the server and reception by the client of the final BindResponse in the SASL exchange with a resultCode of success.
SASL层在服务器传输和客户端接收SASL交换中的最终BindResponse后生效，结果代码为success。
Once a SASL layer providing data integrity or confidentiality services takes effect, the layer remains in effect until a new layer is installed (i.e., at the first octet following the final BindResponse of the Bind operation that caused the new layer to take effect). Thus, an established SASL layer is not affected by a failed or non-SASL Bind.
一旦提供数据完整性或机密性服务的SASL层生效，该层将保持有效，直到安装新层为止（即，在导致新层生效的绑定操作的最终BindResponse之后的第一个八位组）。因此，已建立的SASL层不受失败或非SASL绑定的影响。
Clients may determine the SASL mechanisms a server supports by reading the 'supportedSASLMechanisms' attribute from the root DSE (DSA-Specific Entry) ([RFC4512], Section 5.1). The values of this attribute, if any, list the mechanisms the server supports in the current LDAP session state. LDAP servers SHOULD allow all clients -- even those with an anonymous authorization -- to retrieve the 'supportedSASLMechanisms' attribute of the root DSE both before and after the SASL authentication exchange. The purpose of the latter is to allow the client to detect possible downgrade attacks (see Section 6.4 and [RFC4422], Section 6.1.2).
客户端可以通过从根DSE（DSA特定条目）（[RFC4512]，第5.1节）读取“supportedSASLMechanisms”属性来确定服务器支持的SASL机制。此属性的值（如果有）列出了服务器在当前LDAP会话状态下支持的机制。LDAP服务器应允许所有客户端（即使是具有匿名授权的客户端）在SASL身份验证交换之前和之后检索根DSE的“supportedSASLMechanisms”属性。后者的目的是允许客户端检测可能的降级攻击（参见第6.4节和[RFC4422]第6.1.2节）。
Because SASL mechanisms provide critical security functions, clients and servers should be configurable to specify what mechanisms are acceptable and allow only those mechanisms to be used. Both clients and servers must confirm that the negotiated security level meets their requirements before proceeding to use the session.
因为SASL机制提供了关键的安全功能，所以客户端和服务器应该是可配置的，以指定哪些机制是可接受的，并且只允许使用那些机制。在继续使用会话之前，客户端和服务器都必须确认协商的安全级别满足其要求。
Upon installing a SASL layer, the client SHOULD discard or refresh all information about the server that it obtained prior to the initiation of the SASL negotiation and that it did not obtain through secure mechanisms.
安装SASL层后，客户机应放弃或刷新在启动SASL协商之前获得的且未通过安全机制获得的有关服务器的所有信息。
If a lower-level security layer (such as TLS) is installed, any SASL layer SHALL be layered on top of such security layers regardless of the order of their negotiation. In all other respects, the SASL layer and other security layers act independently, e.g., if both a TLS layer and a SASL layer are in effect, then removing the TLS layer does not affect the continuing service of the SASL layer.
如果安装了较低级别的安全层（如TLS），则任何SASL层都应分层在此类安全层的顶部，而不管其协商顺序如何。在所有其它方面，SASL层和其它安全层独立地动作，例如，如果TLS层和SASL层都有效，则移除TLS层不会影响SASL层的持续服务。
LDAP supports multiple SASL authentications as defined in [RFC4422], Section 4.
LDAP支持[RFC4422]第4节中定义的多个SASL身份验证。
Some SASL mechanisms allow clients to request a desired authorization identity for the LDAP session ([RFC4422], Section 3.4). The decision to allow or disallow the current authentication identity to have access to the requested authorization identity is a matter of local policy. The authorization identity is a string of UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the following Augmented Backus-Naur Form (ABNF) [RFC4234] grammar:
一些SASL机制允许客户端为LDAP会话请求所需的授权标识（[RFC4422]，第3.4节）。允许或不允许当前身份验证标识访问请求的授权标识的决定取决于本地策略。授权标识是一个UTF-8[RFC3629]编码的[Unicode]字符字符串，对应于以下扩充的巴科斯瑙格式（ABNF）[RFC4234]语法：
authzId = dnAuthzId / uAuthzId
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id dnAuthzId = "dn:" distinguishedName
; 基于可分辨名称的authz id dnAuthzId=“dn:”可分辨名称
; unspecified authorization id, UTF-8 encoded
uAuthzId = "u:" userid
userid = *UTF8 ; syntax unspecified
; unspecified authorization id, UTF-8 encoded
uAuthzId = "u:" userid
userid = *UTF8 ; syntax unspecified
where the distinguishedName rule is defined in Section 3 of [RFC4514] and the UTF8 rule is defined in Section 1.4 of [RFC4512].
其中，[RFC4514]第3节定义了DifferentiedName规则，而[RFC4512]第1.4节定义了UTF8规则。
The dnAuthzId choice is used to assert authorization identities in the form of a distinguished name to be matched in accordance with the distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15). There is no requirement that the asserted distinguishedName value be that of an entry in the directory.
dnAuthzId选项用于根据DifferentiedNameMatch匹配规则（[RFC4517]，第4.2.15节）以要匹配的可分辨名称的形式声明授权标识。不要求断言的DifferentizedName值是目录中某个条目的值。
The uAuthzId choice allows clients to assert an authorization identity that is not in distinguished name form. The format of userid is defined only as a sequence of UTF-8 [RFC3629] encoded [Unicode] characters, and any further interpretation is a local matter. For example, the userid could identify a user of a specific directory service, be a login name, or be an email address. A uAuthzId SHOULD NOT be assumed to be globally unique. To compare uAuthzId values, each uAuthzId value MUST be prepared as a "query" string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm, and then the two values are compared octet-wise.
uAuthzId选项允许客户端断言非可分辨名称形式的授权标识。userid的格式仅定义为UTF-8[RFC3629]编码的[Unicode]字符序列，任何进一步的解释都是局部问题。例如，userid可以标识特定目录服务的用户、登录名或电子邮件地址。不应假定uAuthzId是全球唯一的。要比较uAuthzId值，必须使用SASLprep[RFC4013]算法将每个uAuthzId值准备为一个“查询”字符串（[RFC3454]，第7节），然后按八位字节比较这两个值。
The above grammar is extensible. The authzId production may be extended to support additional forms of identities. Each form is distinguished by its unique prefix (see Section 3.12 of [RFC4520] for registration requirements).
上述语法是可扩展的。authzId产品可以扩展以支持其他形式的身份。每个表格都有其唯一的前缀（注册要求见[RFC4520]第3.12节）。
Implementers must take care to maintain the semantics of SASL specifications when handling data that has different semantics in the LDAP protocol.
在处理LDAP协议中具有不同语义的数据时，实现者必须注意维护SASL规范的语义。
For example, the SASL DIGEST-MD5 authentication mechanism [DIGEST-MD5] utilizes an authentication identity and a realm that are syntactically simple strings and semantically simple username [RFC4013] and realm values. These values are not LDAP DNs, and there is no requirement that they be represented or treated as such.
例如，SASL DIGEST-MD5身份验证机制[DIGEST-MD5]利用了一个身份验证标识和一个领域，该领域是语法简单的字符串和语义简单的用户名[RFC4013]以及领域值。这些值不是LDAP DNs，并且不要求将其表示或处理为LDAP DNs。
A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism to request the LDAP server to authenticate and establish a resulting authorization identity using security credentials exchanged by a lower security layer (such as by TLS authentication). If the client's authentication credentials have not been established at a lower security layer, the SASL EXTERNAL Bind MUST fail with a resultCode of inappropriateAuthentication. Although this situation has the effect of leaving the LDAP session in an anonymous state (Section 4), the state of any installed security layer is unaffected.
客户端可以使用SASL外部（[RFC4422]，附录A）机制请求LDAP服务器使用较低安全层（如TLS身份验证）交换的安全凭据进行身份验证并建立最终的授权标识。如果客户端的身份验证凭据尚未在较低的安全层上建立，则SASL外部绑定必须失败，并导致不适当的身份验证代码。尽管这种情况会使LDAP会话保持匿名状态（第4节），但任何已安装的安全层的状态都不会受到影响。
A client may either request that its authorization identity be automatically derived from its authentication credentials exchanged at a lower security layer, or it may explicitly provide a desired authorization identity. The former is known as an implicit assertion, and the latter as an explicit assertion.
客户机可以请求从在较低安全层交换的身份验证凭据自动派生其授权标识，也可以显式提供所需的授权标识。前者称为隐式断言，后者称为显式断言。
An implicit authorization identity assertion is performed by invoking a Bind request of the SASL form using the EXTERNAL mechanism name that does not include the optional credentials field (found within the SaslCredentials sequence in the BindRequest). The server will derive the client's authorization identity from the authentication identity supplied by a security layer (e.g., a public key certificate used during TLS layer installation) according to local policy. The underlying mechanics of how this is accomplished are implementation specific.
隐式授权标识断言是通过使用不包括可选凭证字段（在BindRequest中的SaslCredentials序列中找到）的外部机制名称调用SASL表单的绑定请求来执行的。服务器将根据本地策略从安全层提供的身份验证标识（例如，在TLS层安装期间使用的公钥证书）派生客户端的授权标识。如何实现这一点的基本机制是特定于实现的。
An explicit authorization identity assertion is performed by invoking a Bind request of the SASL form using the EXTERNAL mechanism name that includes the credentials field (found within the SaslCredentials sequence in the BindRequest). The value of the credentials field (an OCTET STRING) is the asserted authorization identity and MUST be constructed as documented in Section 5.2.1.8.
显式授权标识断言是通过使用包含凭证字段（位于BindRequest中的SaslCredentials序列中）的外部机制名称调用SASL表单的绑定请求来执行的。凭证字段的值（八位字节字符串）是断言的授权标识，必须按照第5.2.1.8节中的说明进行构造。
Security issues are discussed throughout this document. The unsurprising conclusion is that security is an integral and necessary part of LDAP. This section discusses a number of LDAP-related security considerations.
本文档中讨论了安全问题。毫不奇怪的结论是，安全性是LDAP不可或缺的一部分。本节讨论一些与LDAP相关的安全注意事项。
LDAP itself provides no security or protection from accessing or updating the directory by means other than through the LDAP protocol, e.g., from inspection of server database files by database administrators.
LDAP本身不提供通过LDAP协议以外的方式访问或更新目录的安全性或保护，例如数据库管理员检查服务器数据库文件。
Sensitive data may be carried in almost any LDAP message, and its disclosure may be subject to privacy laws or other legal regulation in many countries. Implementers should take appropriate measures to protect sensitive data from disclosure to unauthorized entities.
敏感数据几乎可以在任何LDAP消息中携带，其披露可能受到许多国家隐私法或其他法律法规的约束。实施者应采取适当措施，保护敏感数据不被披露给未经授权的实体。
A session on which the client has not established data integrity and privacy services (e.g., via StartTLS, IPsec, or a suitable SASL mechanism) is subject to man-in-the-middle attacks to view and modify information in transit. Client and server implementers SHOULD take measures to protect sensitive data in the LDAP session from these attacks by using data protection services as discussed in this document. Clients and servers should provide the ability to be configured to require these protections. A resultCode of
客户端尚未建立数据完整性和隐私服务（例如，通过StartTLS、IPsec或适当的SASL机制）的会话会受到中间人攻击，以查看和修改传输中的信息。客户端和服务器实现者应采取措施，通过使用本文档中讨论的数据保护服务，保护LDAP会话中的敏感数据免受这些攻击。客户机和服务器应能够配置为需要这些保护。结果代码
confidentialityRequired indicates that the server requires establishment of (stronger) data confidentiality protection in order to perform the requested operation.
机密性Required表示服务器需要建立（更强的）数据机密性保护才能执行请求的操作。
Access control should always be applied when reading sensitive information or updating directory information.
读取敏感信息或更新目录信息时，应始终应用访问控制。
Various security factors, including authentication and authorization information and data security services may change during the course of the LDAP session, or even during the performance of a particular operation. Implementations should be robust in the handling of changing security factors.
各种安全因素（包括身份验证和授权信息以及数据安全服务）可能在LDAP会话过程中，甚至在执行特定操作过程中发生变化。在处理不断变化的安全因素时，实现应该是健壮的。
All security gained via use of the StartTLS operation is gained by the use of TLS itself. The StartTLS operation, on its own, does not provide any additional security.
通过使用StartTLS操作获得的所有安全性都是通过使用TLS本身获得的。StartTLS操作本身不提供任何额外的安全性。
The level of security provided through the use of TLS depends directly on both the quality of the TLS implementation used and the style of usage of that implementation. Additionally, a man-in-the-middle attacker can remove the StartTLS extended operation from the 'supportedExtension' attribute of the root DSE. Both parties SHOULD independently ascertain and consent to the security level achieved once TLS is established and before beginning use of the TLS-protected session. For example, the security level of the TLS layer might have been negotiated down to plaintext.
通过使用TLS提供的安全级别直接取决于所用TLS实现的质量和该实现的使用风格。此外，中间人攻击者可以从根DSE的“supportedExtension”属性中删除StartTLS扩展操作。一旦TLS建立，在开始使用受TLS保护的会话之前，双方应独立确定并同意达到的安全级别。例如，TLS层的安全级别可能已协商为明文。
Clients MUST either warn the user when the security level achieved does not provide an acceptable level of data confidentiality and/or data integrity protection, or be configurable to refuse to proceed without an acceptable level of security.
当达到的安全级别不能提供可接受的数据机密性和/或数据完整性保护时，客户端必须警告用户，或者可以配置为在没有可接受的安全级别的情况下拒绝继续。
As stated in Section 3.1.2, a server may use a local security policy to determine whether to successfully complete TLS negotiation. Information in the user's certificate that is originated or verified by the certification authority should be used by the policy administrator when configuring the identification and authorization policy.
如第3.1.2节所述，服务器可以使用本地安全策略来确定是否成功完成TLS协商。在配置标识和授权策略时，策略管理员应使用由证书颁发机构发起或验证的用户证书中的信息。
Server implementers SHOULD allow server administrators to elect whether and when data confidentiality and integrity are required, as well as elect whether authentication of the client during the TLS handshake is required.
服务器实现者应允许服务器管理员选择是否以及何时需要数据机密性和完整性，以及选择是否需要在TLS握手期间对客户端进行身份验证。
Implementers should be aware of and understand TLS security considerations as discussed in the TLS specification [RFC4346].
实施者应了解TLS规范[RFC4346]中讨论的TLS安全注意事项。
This section discusses several security considerations relevant to LDAP authentication via the Bind operation.
本节讨论与通过绑定操作进行LDAP身份验证相关的几个安全注意事项。
Operational experience shows that clients can (and frequently do) misuse the unauthenticated authentication mechanism of the simple Bind method (see Section 5.1.2). For example, a client program might make a decision to grant access to non-directory information on the basis of successfully completing a Bind operation. LDAP server implementations may return a success response to an unauthenticated Bind request. This may erroneously leave the client with the impression that the server has successfully authenticated the identity represented by the distinguished name when in reality, an anonymous authorization state has been established. Clients that use the results from a simple Bind operation to make authorization decisions should actively detect unauthenticated Bind requests (by verifying that the supplied password is not empty) and react appropriately.
运营经验表明，客户可以（并且经常）滥用简单绑定方法的未经验证的身份验证机制（见第5.1.2节）。例如，客户机程序可能会在成功完成绑定操作的基础上决定授予对非目录信息的访问权。LDAP服务器实现可能会对未经验证的绑定请求返回成功响应。这可能会错误地给客户端留下这样的印象，即当实际上已经建立匿名授权状态时，服务器已经成功地验证了由可分辨名称表示的身份。使用简单绑定操作的结果做出授权决策的客户端应主动检测未经验证的绑定请求（通过验证提供的密码是否为空），并做出适当的反应。
The name/password authentication mechanism of the simple Bind method discloses the password to the server, which is an inherent security risk. There are other mechanisms, such as SASL DIGEST-MD5 [DIGEST-MD5], that do not disclose the password to the server.
简单绑定方法的名称/密码认证机制向服务器公开密码，这是一种固有的安全风险。还有其他机制，例如SASL DIGEST-MD5[DIGEST-MD5]，它们不会向服务器公开密码。
LDAP allows multi-valued password attributes. In systems where entries are expected to have one and only one password, administrative controls should be provided to enforce this behavior.
LDAP允许多值密码属性。在预期条目只有一个密码的系统中，应提供管理控制以强制执行此行为。
The use of clear text passwords and other unprotected authentication credentials is strongly discouraged over open networks when the underlying transport service cannot guarantee confidentiality. LDAP implementations SHOULD NOT by default support authentication methods using clear text passwords and other unprotected authentication credentials unless the data on the session is protected using TLS or other data confidentiality and data integrity protection.
当基础传输服务无法保证机密性时，强烈建议在开放网络上使用明文密码和其他不受保护的身份验证凭据。默认情况下，LDAP实现不应支持使用明文密码和其他未受保护的身份验证凭据的身份验证方法，除非会话上的数据使用TLS或其他数据机密性和数据完整性保护进行保护。
The transmission of passwords in the clear -- typically for authentication or modification -- poses a significant security risk. This risk can be avoided by using SASL authentication [RFC4422]
以明文形式传输密码（通常用于身份验证或修改）会带来严重的安全风险。使用SASL身份验证[RFC4422]可以避免这种风险
mechanisms that do not transmit passwords in the clear or by negotiating transport or session layer data confidentiality services before transmitting password values.
在传输密码值之前，不以明文或协商传输或会话层数据保密服务的方式传输密码的机制。
To mitigate the security risks associated with the transfer of passwords, a server implementation that supports any password-based authentication mechanism that transmits passwords in the clear MUST support a policy mechanism that at the time of authentication or password modification, requires that:
为了减轻与密码传输相关的安全风险，支持任何基于密码的身份验证机制（以明文形式传输密码）的服务器实现必须支持一种策略机制，该机制在身份验证或密码修改时要求：
A TLS layer has been successfully installed.
已成功安装TLS层。
OR
或
Some other data confidentiality mechanism that protects the password value from eavesdropping has been provided.
还提供了一些保护密码值不被窃听的其他数据保密机制。
OR
或
The server returns a resultCode of confidentialityRequired for the operation (i.e., name/password Bind with password value, SASL Bind transmitting a password value in the clear, add or modify including a userPassword value, etc.), even if the password value is correct.
即使密码值正确，服务器也会返回操作所需的机密代码resultCode（即，名称/密码与密码值绑定，SASL绑定以清除、添加或修改方式传输密码值，包括用户密码值等）。
Server implementations may also want to provide policy mechanisms to invalidate or otherwise protect accounts in situations where a server detects that a password for an account has been transmitted in the clear.
服务器实现可能还希望提供策略机制，以便在服务器检测到帐户密码已以明文形式传输的情况下使帐户无效或以其他方式保护帐户。
Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of the password value that may be vulnerable to offline dictionary attacks. Implementers should take care to protect such hashed password values during transmission using TLS or other confidentiality mechanisms.
某些身份验证机制（例如DIGEST-MD5）传输密码值的散列，可能容易受到脱机字典攻击。实现者应该注意使用TLS或其他保密机制在传输过程中保护这些散列密码值。
Until data integrity service is installed on an LDAP session, an attacker can modify the transmitted values of the 'supportedSASLMechanisms' attribute response and thus downgrade the list of available SASL mechanisms to include only the least secure mechanism. To detect this type of attack, the client may retrieve the SASL mechanisms the server makes available both before and after data integrity service is installed on an LDAP session. If the client finds that the integrity-protected list (the list obtained
在LDAP会话上安装数据完整性服务之前，攻击者可以修改“supportedSASLMechanisms”属性响应的传输值，从而降级可用SASL机制列表，使其仅包含最不安全的机制。要检测这种类型的攻击，客户端可以检索服务器在LDAP会话上安装数据完整性服务之前和之后提供的SASL机制。如果客户端发现完整性保护列表（获取的列表
after data integrity service was installed) contains a stronger mechanism than those in the previously obtained list, the client should assume the previously obtained list was modified by an attacker. In this circumstance it is recommended that the client close the underlying transport connection and then reconnect to reestablish the session.
安装数据完整性服务（data integrity service）后，客户端应假定先前获取的列表已被攻击者修改，该列表包含比先前获取的列表更强的机制。在这种情况下，建议客户端关闭基础传输连接，然后重新连接以重新建立会话。
Additional security considerations relating to the various authentication methods and mechanisms discussed in this document apply and can be found in [RFC4422], [RFC4013], [RFC3454], and [RFC3629].
与本文档中讨论的各种身份验证方法和机制相关的其他安全注意事项适用，可在[RFC4422]、[RFC4013]、[RFC3454]和[RFC3629]中找到。
The IANA has updated the LDAP Protocol Mechanism registry to indicate that this document and [RFC4511] provide the definitive technical specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended operation.
IANA已更新了LDAP协议机制注册表，表明本文件和[RFC4511]为StartTLS（1.3.6.1.4.1.1466.20037）扩展操作提供了最终技术规范。
The IANA has updated the LDAP LDAPMessage types registry to indicate that this document and [RFC4511] provide the definitive technical specification for the bindRequest (0) and bindResponse (1) message types.
IANA已更新LDAP LDAPMessage types注册表，以表明本文档和[RFC4511]为bindRequest（0）和bindResponse（1）消息类型提供了最终技术规范。
The IANA has updated the LDAP Bind Authentication Method registry to indicate that this document and [RFC4511] provide the definitive technical specification for the simple (0) and sasl (3) bind authentication methods.
IANA已经更新了LDAP绑定身份验证方法注册表，表明本文档和[RFC4511]为简单（0）和sasl（3）绑定身份验证方法提供了明确的技术规范。
The IANA has updated the LDAP authzid prefixes registry to indicate that this document provides the definitive technical specification for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.
IANA已更新LDAP authzid前缀注册表，以表明本文档提供了dnAuthzId（dn:）和uAuthzId（u:）authzid前缀的最终技术规范。
This document combines information originally contained in RFC 2251, RFC 2829, and RFC 2830. RFC 2251 was a product of the Access, Searching, and Indexing of Directories (ASID) Working Group. RFC 2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT) Working Group.
本文档结合了RFC 2251、RFC 2829和RFC 2830中最初包含的信息。RFC2251是目录访问、搜索和索引（ASID）工作组的产品。RFC2829和RFC2830是LDAP扩展（LDAPEXT）工作组的产品。
This document is a product of the IETF LDAP Revision (LDAPBIS) working group.
本文件是IETF LDAP修订（LDAPBIS）工作组的产品。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, March 2006.
2006年3月，第34C.46版和第34RFC.46版。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512]Zeilenga，K.，“轻量级目录访问协议（LDAP）：目录信息模型”，RFC4512，2006年6月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]Legg，S.，Ed.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC4517，2006年6月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519]Sciberras，A.，Ed.，“轻量级目录访问协议（LDAP）：用户应用程序模式”，RFC4519，2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 4520，2006年6月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633- 5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[Unicode]Unicode联盟“Unicode标准，版本3.2.0”由“Unicode标准，版本3.0”（雷丁，马萨诸塞州，Addison-Wesley，2000年。ISBN 0-201-61633-5）定义，并由“Unicode标准附录27:Unicode 3.1”修订(http://www.unicode.org/reports/tr27/)根据“Unicode标准附录28:Unicode 3.2”(http://www.unicode.org/reports/tr28/).
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[X.501]ITU-T Rec.X.501，“目录：模型”，1993年。
[DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest Authentication as a SASL Mechanism", Work in Progress, March 2006.
[DIGEST-MD5]Leach，P.，Newman，C.，和A.Melnikov，“使用摘要认证作为SASL机制”，正在进行的工作，2006年3月。
[PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in Progress, March 2005.
[平原]Zeilenga，K.，“平原SASL机制”，正在进行的工作，2005年3月。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828]Shirey，R.，“互联网安全词汇表”，FYI 36，RFC 2828，2000年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505, June 2006.
[RFC4505]Zeilenga，K.，“匿名SASL机制”，RFC4505，2006年6月。
This appendix is non-normative.
本附录为非规范性附录。
This appendix 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. Security objects and mechanisms, such as those described here, enable the expression of access control policies and their enforcement.
访问控制策略是定义资源保护的一组规则，通常根据访问这些资源的个人或其他实体的能力来定义。安全对象和机制（如本文所述）支持访问控制策略的表达及其实施。
A request, when it is being processed by a server, may be associated with a wide variety of security-related factors. 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 transport connection via which the request is transmitted; and others (e.g., time of day) may be "environmental".
当服务器处理请求时，请求可能与多种安全相关因素相关联。服务器使用这些因素来确定是否以及如何处理请求。这些被称为访问控制因素（ACF）。它们可能包括源IP地址、加密强度、请求的操作类型、一天中的时间等。。有些因素可能是特定于请求本身的；其他可与传输请求所经由的传输连接相关联；而其他（例如，一天中的某个时间）可能是“环境的”。
Access control policies are expressed in terms of access control factors; for example, "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”。服务器为此类表达式提供的ACF集是特定于实现的。
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 a new authorization state 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. X.509 certificates, Kerberos tickets, and simple identity and password pairs are all examples of authentication
有多种形式的身份验证凭据。所使用的形式取决于双方协商的特定认证机制。X.509证书、Kerberos票据以及简单的身份和密码对都是身份验证的示例
credential forms. Note that an authentication mechanism may constrain the form of authentication identities used with it.
凭证表格。请注意，身份验证机制可能会约束与其一起使用的身份验证标识的形式。
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; for example, "entity X can perform operation Y on resource Z".
授权标识是一种访问控制因素。它是请求执行操作的用户或其他实体的名称。访问控制策略通常以授权身份表示；例如，“实体X可以对资源Z执行操作Y”。
The authorization identity of an LDAP session is often semantically 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 [RFC4422]. 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, thus 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.
LDAP会话的授权标识通常在语义上与客户端提供的身份验证标识相同，但可能有所不同。SASL允许客户端指定不同于客户端凭据断言的身份验证标识的授权标识。这允许代理服务器（如代理服务器）使用其自己的凭据进行身份验证，同时请求其代理的身份的访问权限[RFC4422]。此外，由类似TLS的服务提供的认证标识的形式可能与用于表示服务器的访问控制策略的授权标识不对应，因此需要进行特定于服务器的映射。服务器根据客户端提供的身份验证凭据组合和验证授权标识的方法是特定于实现的。
This appendix is non-normative.
本附录为非规范性附录。
This appendix summarizes substantive changes made to RFC 2251, RFC 2829 and RFC 2830. In addition to the specific changes detailed below, the reader of this document should be aware that numerous general editorial changes have been made to the original content from the source documents. These changes include the following:
本附录总结了对RFC 2251、RFC 2829和RFC 2830所做的实质性更改。除下文详述的具体变更外，本文件的读者还应注意，对源文件的原始内容进行了大量的一般性编辑变更。这些变化包括：
- The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2, RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was combined into a single document.
- 最初在RFC 2251第4.2.1节和第4.2.2节、RFC 2829（除第2节和第4节外的所有章节）以及RFC 2830中找到的材料被合并为一份文件。
- The combined material was substantially reorganized and edited to group related subjects, improve the document flow, and clarify intent.
- 对合并材料进行了实质性的重组和编辑，以对相关主题进行分组，改进文件流程，并澄清意图。
- Changes were made throughout the text to align with definitions of LDAP protocol layers and IETF security terminology.
- 全文进行了更改，以符合LDAP协议层和IETF安全术语的定义。
- Substantial updates and additions were made to security considerations from both documents based on current operational experience.
- 根据目前的业务经验，对两份文件中的安全注意事项进行了大量更新和补充。
This section summarizes the substantive changes made to Sections 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional substantive changes to Section 4.2.1 of RFC 2251 are also documented in [RFC4511].
本节总结了本文件对RFC 2251第4.2.1节和第4.2.2节所做的实质性更改。RFC 2251第4.2.1节的其他实质性变更也记录在[RFC4511]中。
- Paragraph 1: Removed the sentence, "If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection". The Unbind operation still permits this behavior, but it is not documented explicitly.
- 第1段：删除了“如果在任何阶段，客户端希望中止绑定过程，则可以解除绑定，然后放弃底层连接”这句话。解除绑定操作仍然允许这种行为，但没有明确的文档记录。
- Clarified that the session is moved to an anonymous state upon receipt of the BindRequest PDU and that it is only moved to a non-anonymous state if and when the Bind request is successful.
- 阐明了在收到BindRequest PDU时，会话将移动到匿名状态，并且只有在Bind请求成功时，会话才会移动到非匿名状态。
- RFC 2251 states that anonymous authentication MUST be performed using the simple bind method. This specification defines the anonymous authentication mechanism of the simple bind method and requires all conforming implementations to support it. Other authentication mechanisms producing anonymous authentication and authorization state may also be implemented and used by conforming implementations.
- RFC2251声明匿名身份验证必须使用简单绑定方法执行。本规范定义了简单绑定方法的匿名身份验证机制，并要求所有符合要求的实现都支持该机制。产生匿名认证和授权状态的其他认证机制也可以由一致性实现来实现和使用。
This section summarizes the substantive changes made to RFC 2829.
本节总结了对RFC 2829所做的实质性更改。
- The name/password authentication mechanism (see Section B.2.5 below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as LDAP's mandatory-to-implement password-based authentication mechanism. Implementations are encouraged to continue supporting SASL DIGEST-MD5 [DIGEST-MD5].
- 受TLS保护的名称/密码身份验证机制（见下面的B.2.5节）取代了SASL DIGEST-MD5机制，成为LDAP实现基于密码的身份验证机制的必备机制。鼓励实现继续支持SASL DIGEST-MD5[DIGEST-MD5]。
- Clarified that anonymous authentication involves a name value of zero length and a password value of zero length. The unauthenticated authentication mechanism was added to handle simple Bind requests involving a name value with a non-zero length and a password value of zero length.
- 阐明匿名身份验证涉及长度为零的名称值和长度为零的密码值。添加了未经验证的身份验证机制来处理简单的绑定请求，该绑定请求涉及长度为非零的名称值和长度为零的密码值。
- See Section B.2.1.
- 见第B.2.1节。
- As the SASL-DIGEST-MD5 mechanism is no longer mandatory to implement, this section is now historical and was not included in this document. RFC 2829, Section 6.1, continues to document the SASL DIGEST-MD5 authentication mechanism.
- 由于SASL-DIGEST-MD5机制不再是强制实施的，因此本节现已成为历史，未包含在本文档中。RFC 2829第6.1节继续记录SASL DIGEST-MD5认证机制。
B.2.5. Section 6.2 ("'simple' authentication choice under TLS encryption")
B.2.5. 第6.2节（“TLS加密下的“简单”认证选择”）
- Renamed the "simple" authentication mechanism to the name/password authentication mechanism to better describe it.
- 将“简单”身份验证机制重命名为名称/密码身份验证机制以更好地描述它。
- The use of TLS was generalized to align with definitions of LDAP protocol layers. TLS establishment is now discussed as an independent subject and is generalized for use with all authentication mechanisms and other security layers.
- TLS的使用得到了推广，以与LDAP协议层的定义保持一致。TLS建立现在作为一个独立的主题进行讨论，并被推广用于所有身份验证机制和其他安全层。
- Removed the implication that the userPassword attribute is the sole location for storage of password values to be used in authentication. There is no longer any implied requirement for how or where passwords are stored at the server for use in authentication.
- 删除了userPassword属性是存储身份验证中使用的密码值的唯一位置的含义。对于在服务器上存储密码以用于身份验证的方式或位置，不再存在任何隐含要求。
- See Section B.2.5.
- 见第B.2.5节。
- See Section B.2.5.
- 见第B.2.5节。
- All SASL authentication mechanisms are explicitly allowed within LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN mechanisms are no longer precluded from use within LDAP.
- LDAP中明确允许所有SASL身份验证机制。具体来说，这意味着不再禁止在LDAP中使用SASL匿名和SASL普通机制。
- Specified matching rules for dnAuthzId and uAuthzId values. In particular, the DN value in the dnAuthzId form must be matched using DN matching rules, and the uAuthzId value MUST be prepared using SASLprep rules before being compared octet-wise.
- 为dnAuthzId和uAuthzId值指定了匹配规则。特别是，dnAuthzId表单中的DN值必须使用DN匹配规则进行匹配，而uAuthzId值必须使用SASLprep规则进行准备，然后才能按八位字节进行比较。
- Clarified that uAuthzId values should not be assumed to be globally unique.
- 阐明不应假设uAuthzId值为全局唯一值。
- TLS ciphersuite recommendations are no longer included in this specification. Implementations must now support the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
- TLS ciphersuite建议不再包含在本规范中。实施现在必须支持TLS\U RSA\U和CBC\U SHA密码套件，并应继续支持TLS\U DHE\U DSS\U和CBC\U密码套件。
- Clarified that anonymous authentication involves a name value of zero length and a password value of zero length. The unauthenticated authentication mechanism was added to handle simple Bind requests involving a name value with a non-zero length and a password value of zero length.
- 阐明匿名身份验证涉及长度为零的名称值和长度为零的密码值。添加了未经验证的身份验证机制来处理简单的绑定请求，该绑定请求涉及长度为非零的名称值和长度为零的密码值。
This section summarizes the substantive changes made to Sections 3 and 5 of RFC 2830. Readers should consult [RFC4511] for summaries of changes to other sections.
本节总结了对RFC 2830第3节和第5节所做的实质性修改。读者应参考[RFC4511]了解其他章节的变更摘要。
- Substantially updated the server identity check algorithm to ensure that it is complete and robust. In particular, the use of all relevant values in the subjectAltName and the subjectName fields are covered by the algorithm and matching rules are specified for each type of value. Mapped (derived) forms of the server identity may now be used when the mapping is performed in a secure fashion.
- 大幅更新了服务器身份检查算法，以确保其完整性和健壮性。特别是，算法涵盖subjectAltName和subjectName字段中所有相关值的使用，并为每种类型的值指定匹配规则。当以安全方式执行映射时，现在可以使用服务器标识的映射（派生）形式。
- Clients are no longer required to always refresh information about server capabilities following TLS establishment. This is to allow for situations where this information was obtained through a secure mechanism.
- 在TLS建立之后，客户端不再需要始终刷新有关服务器功能的信息。这是为了考虑通过安全机制获取信息的情况。
B.3.3. Section 5 ("Effects of TLS on a Client's Authorization Identity")
B.3.3. 第5节（“TLS对客户授权身份的影响”）
- Establishing a TLS layer on an LDAP session may now cause the authorization state of the LDAP session to change.
- 在LDAP会话上建立TLS层现在可能会导致LDAP会话的授权状态发生更改。
- Closing a TLS layer on an LDAP session changes the authentication and authorization state of the LDAP session based on local policy. Specifically, this means that implementations are not required to change the authentication and authorization states to anonymous upon TLS closure.
- 关闭LDAP会话上的TLS层会根据本地策略更改LDAP会话的身份验证和授权状态。具体来说，这意味着在TLS关闭时，不需要实现将身份验证和授权状态更改为匿名。
- Replaced references to RFC 2401 with RFC 4301.
- 将对RFC 2401的引用替换为RFC 4301。
Author's Address
作者地址
Roger Harrison Novell, Inc. 1800 S. Novell Place Provo, UT 84606 USA
罗杰·哈里森·诺维尔公司，美国犹他州普罗沃诺维尔广场南1800号，邮编84606
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。