[要約] 要約： RFC 4513は、LDAPの認証方法とセキュリティメカニズムに関する標準仕様です。このRFCの目的は、LDAPを使用して安全な認証を実現するためのガイドラインを提供することです。目的： 1. LDAPの認証方法とセキュリティメカニズムに関する標準仕様を提供する。 2. LDAPを使用して安全な認証を実現するためのガイドラインを提供する。 3. LDAPのセキュリティに関するベストプラクティスを示す。
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
Lightweight Directory Access Protocol（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).
Copyright（c）The Internet Society（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.
このドキュメントでは、匿名、認証、名前/パスワードメカニズムを含むシンプルなバインド認証方法と、外部メカニズムを含むSimple認証およびセキュリティレイヤー（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を参照）、Obsoletes 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
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.
Lightweight Directory Access Protocol（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.
これらのセキュリティ機能は、インターネット上のすべての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) Data-Retrieval操作を介したディレクトリデータへの不正アクセス。
(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) バインド操作による認証。BIND操作は、匿名、認証、名前/パスワードメカニズムをサポートする簡単な方法と、さまざまな認証メカニズムをサポートするSimple認証およびセキュリティレイヤー（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は、IPレイヤーセキュリティ[RFC4301]を使用して、LDAPプロトコル以外の手段によって保護される場合があります。
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のセクション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.
RFC 2830のセクション2と4は、[RFC4511]によって廃止されています。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].
「しなければならない」、「そうしない」、「そうする必要はありません」、「そうは思わない」、「そうすべきではない」、「5月」、および「オプション」は、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セッション」という用語は、組み合わせサービス（Transport Connection、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）の名前/パスワード認証メカニズムをサポートする必要があり、TLSを使用してこの名前/パスワード認証を保護できる必要があります。StartTLS操作によって確立されているように（セクション3）。
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外部メカニズムを介して認証IDのクライアントアサーションをサポートする必要があります（セクション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.) 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.
単純なバインド法の匿名メカニズム以外の認証メカニズムをサポートしないLDAPサーバーの実装は、StartTLS操作によって確立されたTLSの使用をサポートする必要があります（セクション3）。（他のサーバーは、このセクションの2番目の段落ごとにTLSをサポートする必要があります。）TLSをサポートする実装は、TLS_RSA_WITH_WITH_3DES_EDE_CBC_SHA CIPHERSUITEをサポートする必要があります。以前のLDAP StartTLS仕様に準拠した実装との相互運用性を促進するために、後者のCiphersuiteのサポートをお勧めします。
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で定義されているStart Transport Layer Security（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の認証サービスはLDAPがSASL外部認証方法と組み合わせてのみ使用できます（セクション5.2.3を参照）、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設立のために従わなければならない全体的な手順について説明します。これらの手順は、結果として生じるセキュリティレベルの発見やクライアントの認可IDのアサーションなど、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、これらの要件のいずれかの（検出）違反により、OperationError 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操作を実行して、BINDリクエストと応答メッセージが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".
中間の攻撃を防ぐために、クライアントはサーバーのIDを確認する必要があります（サーバーの証明書メッセージに示されているように）。このセクションでは、クライアントのサーバーのID（通常、輸送接続の確立に使用されるID）に対するクライアントの理解は、「参照ID」と呼ばれます。
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.
クライアントは、参照IDのタイプ（DNS名またはIPアドレスなど）を決定し、一致が生成されるまで、参照IDと対応するタイプの各subjectaltName値との比較を実行します。一致が作成されると、サーバーのIDが検証され、サーバーIDのチェックが完了します。異なるsubmestaltnameタイプは、さまざまな方法で一致しています。セクション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 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).
クライアントは、比較を実行する前に、参照IDを別のタイプにマッピングできます。マッピングは、参照IDをマッピングできるすべての利用可能なsubmentaltnameタイプに対して実行できます。ただし、参照IDは、マッピングが本質的に安全なタイプにのみマッピングする必要があります（たとえば、dnsnameのsumberaltnameと比較するためにdns名を抽出して、マッピングが安全な方法で実行される（たとえば、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.
サーバーのIDは、サーバーの証明書の主題フィールドの葉の相対識別名（RDN）の共通名（CN）[RFC4519]値と参照ID [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.
サーバーIDのチェックが失敗した場合、ユーザー指向のクライアントはユーザー（クライアントにユーザーにLDAPセッションを継続する機会を与えることができます）か、トランスポート接続を閉じて、サーバーのIDが疑わしいことを示します。自動化されたクライアントは、トランスポート接続を閉じてから、サーバーのIDが疑わしいかその両方であることを示すエラーを返したりログにしたりする必要があります。
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.
このセクションで説明されているサーバーIDチェックを超えて、クライアントは、提供するように要求されるサービスを提供することがサーバーが許可されていることを確認するために、さらにチェックする準備をする必要があります。クライアントは、この決定を行う際にローカルポリシー情報を利用する必要がある場合があります。
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:
参照IDが国際化されたドメイン名である場合、適合実装は、型DNSNAMEのsumbuctAltName値と比較する前に、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では、「uesestd3asciirules」と呼ばれるフラグを設定します。*ステップ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.
「to-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.
'*'（ascii 42）ワイルドカード文字は、タイプdnsnameのsubjectaltname値で許可され、次にその値の左端（最小重要な）dnsラベルとしてのみ許可されます。このワイルドカードは、サーバー名の左端のDNSラベルと一致します。つまり、件名 *.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.
参照IDがIPアドレスである場合、IDは「ネットワークバイトの順序」Octet文字列表現[RFC791] [RFC2460]に変換する必要があります。IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列には正確に4オクテットが含まれます。IPバージョン6の場合、RFC 2460で指定されているように、オクテット文字列には正確に16のオクテットが含まれます。次に、このOctet文字列は、iPaddressのタイプのsubjectaltname値と比較されます。参照IDオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
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（RE）交渉が完了した直後に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層がインストールされた後、「サポートされたサスルメカニズム」の値は異なる場合があります（具体的には、外部およびプレーン[プレーン]メカニズムは、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.
- ciphersuiteのパスワードや輸送接続を介して送信されるその他のデータに適切な機密性保護を提供する能力。クライアントとサーバーの実装者は、一部の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.
- クライアントとサーバーの実装者は、保護されているパスワードまたはデータの価値と、Ciphersuiteが提供する保護レベルが適切であることを確認するために、Ciphersuiteが提供する機密保護のレベルを慎重に検討する必要があります。
- 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.
- Ciphersuiteの中間攻撃に対する脆弱性（またはその欠如）。ネットワーク構成が中間攻撃の危険性が無視できるようなものでない限り、パスワードや機密データを保護するために、中間攻撃に対して脆弱なCiphersuitesは使用しないでください。
- 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交渉（初期または後続）が完了した後、両方のプロトコルピアは、交渉されたCiphersuiteが提供するセキュリティサービスが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セッションには、関連する認証状態があります。この状態は、（もしあれば）認証状態が確立されたもの、それがどのように確立されたか、どのようなセキュリティサービスが実施されているかなどの多くの要因で構成されています。いくつかの要因は、プロトコルイベント（例：バインド、startTL、または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での承認は地元の問題です。許可の決定を行う上での重要な要因の1つは、認証IDです。BIND操作（[RFC4511]のセクション4.2で定義され、以下のセクション5でさらに説明します）により、クライアントとサーバー間で情報を交換して、LDAPセッションの承認IDを確立することができます。BIND操作は、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セッションが最初に確立されると、セッションには匿名の認証IDがあります。とりわけ、これは、クライアントが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.
バインドリクエストを受け取ると、サーバーはすぐにセッションを匿名の認証状態に移動します。BIND要求が成功した場合、セッションは、関連する認証状態で要求された認証状態に移動されます。それ以外の場合、セッションは匿名の状態のままです。
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.
BIND操作（[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.
バインド要求は通常、目的の認証IDを指定します。また、一部のバインドメカニズムにより、クライアントは承認IDを指定することもできます。承認IDが指定されていない場合、サーバーは実装固有の方法で認証IDからそれを導出します。
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.
承認IDが指定されている場合、サーバーは、クライアントの認証IDが、主張された認証IDを想定する（例えば、プロキシ）を許可されていることを確認する必要があります。サーバーは、クライアントがそれほど許可されていない場合、Bind Responseの無効な結果コードでバインド操作を拒否する必要があります。
The simple authentication method of the Bind Operation provides three authentication mechanisms:
BIND操作の単純な認証方法は、3つの認証メカニズムを提供します。
- 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クライアントは、Simple Bindメソッドの匿名認証メカニズムを使用して、ゼロの長さの名前値を持つバインド要求を送信し、ゼロ長のパスワード値を含む単純な認証選択を指定することにより、匿名認証状態を明示的に確立することができます。
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クライアントは、Simple Bindメソッドの非認知認証メカニズムを使用して、名前値（ゼロ以外の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を参照）。特に、名前/パスワード認証を実行しようとするユーザーは、不注意に空のパスワードを提供するため、実装されていないクライアントが認識されていないアクセスを要求する可能性があります。クライアントは、空のパスワードのユーザー入力以外の手段で、認証されていない認証メカニズムのユーザーを選択することを要求するために実装する必要があります。クライアントは、空のパスワード入力を名前/パスワード認証ユーザーインターフェイスに禁止する必要があります。さらに、サーバーは、デフォルトでは、lunwilltoperformの結果コードを使用して、既定のバインドバインドリクエストに失敗する必要があります。
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クライアントは、Simple Bindメソッドの名前/パスワード認証メカニズムを使用して、名前値（ゼロ以外の長さの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.
このメカニズムで使用されている1つ以上のパスワードのセットを使用して、BINDリクエストで送信されたDNをマップする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の結果コードは、名前値で送信されたDNが構文的に無効であることを示します。InvalidCredentialsの結果コードは、DNが構文的に正しいが、認証の目的では有効ではないこと、パスワードがDNに対して有効ではないこと、またはサーバーが資格情報を無効と見なしていることを示します。成功の結果は、資格情報が有効であり、サーバーがこれらの資格情報が特定しているエンティティにサービスを提供することをいとわないことを示しています。
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.
Simple Bindメソッドの名前/パスワード認証メカニズムは、機密保護がない環境での認証には適していません。
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).
BIND操作の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]とプレーン[プレーン] 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」であり、IANAにSASLサービス名として登録されています。
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).
- バージョンは3です。 -AuthenticationChoiceはSASLです。-SASLCREDENITIALSシーケンスのメカニズム要素には、目的の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 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.
一般に、SASL認証プロトコル交換は、一連のサーバーの課題とクライアント応答で構成されており、その内容はSASLメカニズムに固有および定義されています。したがって、一部のSASL認証メカニズムの場合、BindRequestメッセージを複数回送信することにより、クライアントが1つ以上のサーバーの課題に応答する必要がある場合があります。課題は、saslbindinprogressにresultCodeセットを使用して、bindResponseメッセージを送信するサーバーによって示されます。これは、サーバーがクライアントが認証プロセスを継続するために同じ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メッセージでServersAslCredsフィールド（Octet String）を使用して、各チャレンジを送信します。LDAPクライアントは、BindRequestメッセージのSASLCREDENITIALSシーケンスの資格情報フィールド（Octet String）を使用して、各応答を送信します。SASLが使用されるいくつかのインターネットプロトコルとは異なり、LDAPはテキストベースではなく、これらの課題と応答の値をbase64-変換しないことに注意してください。
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のメカニズムフィールドに異なる値を使用して、またはSASL以外の認証チェックでBindRequestメッセージを送信することにより、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.
サーバーは、結果のコード値がSaslbindinProgressではないバインドリスポンスで応答することにより、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のServersAslcredsフィールドを使用して、サーバーに追加データを送信するように定義されたメカニズムの成功通知を備えたオプションのチャレンジを含めることができます。
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 Exchangeを開始するメッセージに初期応答を伝達するためのオプションのフィールドを提供し、認証交換の結果を示すメッセージに追加データを伝達するためのオプションのフィールドを提供します。これらのフィールドのメカニズム固有のコンテンツは長さがゼロである可能性があるため、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).
ゼロ長の初期応答データは、Saslcredentials.credentialsの存在によって、開始メッセージの初期応答データ、BindRequest PDUと区別されます。クライアントがSASL Exchangeを開始するBindRequestで初期応答を送信するつもりがない場合は、SASLCREDENTIALS.CREDENITIALS OCTET STRINGを省略する必要があります（ゼロ長さのオクテット文字列を含めるのではなく）。
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).
ゼロレングスの追加データは、そのPDUにServersaslcreds Octet String（長さゼロ）の存在によって、結果メッセージの追加の応答データ、BindResponse PDUとは区別されます。サーバーが交換の結果を示すBindResponseメッセージに追加データを送信するつもりがない場合、サーバーはServersAslcreds Octet Stringを省略しなければなりません（ゼロ長さのオクテット文字列を含めるのではなく）。
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のクライアントによるレセプションが成功します。
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レイヤーが有効になると、新しいレイヤーが取り付けられるまでレイヤーが有効になります（つまり、新しいレイヤーを有効にしたバインド操作の最終的なバインド提示に続く最初のオクテットで）。したがって、確立された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認証交換の前後の両方で、すべてのクライアント（匿名の承認を受けた人でも、「supportedsaslmechanisms」属性のルートDSE属性を取得できるようにする必要があります。後者の目的は、クライアントが可能なダウングレード攻撃を検出できるようにすることです（セクション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セッションの希望の認証IDを要求できます（[RFC4422]、セクション3.4）。要求された認証IDにアクセスできるように現在の認証IDを許可または禁止する決定は、ローカルポリシーの問題です。認証アイデンティティは、次の拡張されたバックスノーフォーム（ABNF）[RFC4234]文法に対応する[Unicode]文字をエンコードしたUTF-8 [RFC3629]の文字列です。
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id dnAuthzId = "dn:" distinguishedName
;Distinguished-Nameベースのauthz id dnauthzid = "dn：" distinguishedname
; 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].
distinguednameルールは[RFC4514]のセクション3で定義されており、UTF8ルールは[RFC4512]のセクション1.4で定義されています。
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の選択は、著名な名前の一致ルール（[RFC4517]、セクション4.2.15）に従って一致する著名な名前の形で認証のアイデンティティを主張するために使用されます。主張された著名な名がディレクトリ内のエントリの値であるという要件はありません。
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の形式は、[Unicode]文字をエンコードしたUTF-8 [RFC3629]のシーケンスとしてのみ定義され、さらなる解釈はローカルな問題です。たとえば、ユーザーIDは、特定のディレクトリサービスのユーザーを識別したり、ログイン名にしたり、メールアドレスにしたりできます。uauthzidは、グローバルに一意であると想定すべきではありません。uauthzid値を比較するには、saslprep [rfc4013]アルゴリズムを使用して、各uauthzid値を「クエリ」文字列（[rfc3454]、セクション7）として準備する必要があり、2つの値をオクテットで比較します。
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ではなく、そのように表現または扱われるという要件はありません。
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認証など）で交換されたセキュリティ資格情報を使用して結果の認証IDを認証および確立するよう要求できます。クライアントの認証資格情報がより低いセキュリティレイヤーで確立されていない場合、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.
クライアントは、より低いセキュリティレイヤーで交換された認証資格情報から自動的に導出されることをクライアントに要求するか、目的の認証IDを明示的に提供する場合があります。前者は暗黙の主張として知られており、後者は明示的な主張として知られています。
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のSASLCREDENITIALSシーケンス内にある）を含まない外部メカニズム名を使用して、SASLフォームのバインド要求を呼び出すことにより、暗黙の承認IDアサーションが実行されます。サーバーは、ローカルポリシーに従って、セキュリティレイヤー（たとえば、TLSレイヤーのインストール中に使用される公開鍵証明書など）によって提供される認証IDからクライアントの承認IDを導き出します。これがどのように達成されるかの基礎となるメカニズムは、実装固有です。
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.
明示的な認証IDのアサーションは、資格情報フィールド（BindRequestのSASLCREDENITIALSシーケンス内にある）を含む外部メカニズム名を使用してSASLフォームのバインド要求を呼び出すことにより実行されます。資格情報フィールド（Octet文字列）の値は、主張された承認IDであり、セクション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 confidentialityRequired indicates that the server requires establishment of (stronger) data confidentiality protection in order to perform the requested operation.
クライアントがデータの整合性とプライバシーサービスを確立していないセッション（startTLS、IPSEC、または適切なSASLメカニズムを介して）は、輸送中の情報を表示および修正するために、中間攻撃の対象となります。クライアントとサーバーの実装者は、このドキュメントで説明したようにデータ保護サービスを使用して、これらの攻撃からLDAPセッションの機密データを保護するための措置を講じる必要があります。クライアントとサーバーは、これらの保護を必要とするように構成する機能を提供する必要があります。Requires 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.
このセクションでは、BIND操作を介した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.
Simple Bind Methodの名前/パスワード認証メカニズムは、固有のセキュリティリスクであるサーバーにパスワードを開示します。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を使用すると、多値のパスワード属性が許可されます。エントリが1つのパスワードと1つのパスワードのみがあると予想されるシステムでは、この動作を実施するために管理コントロールを提供する必要があります。
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] mechanisms that do not transmit passwords in the clear or by negotiating transport or session layer data confidentiality services before transmitting password values.
クリアでのパスワードの送信 - 通常、認証または変更のために - は、重大なセキュリティリスクをもたらします。このリスクは、SASL認証[RFC4422]メカニズムを使用して、パスワード値を送信する前にトランスポートまたはセッションレイヤーのデータ機密保持サービスを交渉することにより、SASL認証[RFC4422]メカニズムを使用して回避できます。
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.
サーバーは、操作のために必要な機密保持の結果を返します（つまり、パスワード値で名前/パスワードバインド、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 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.
データ整合性サービスがLDAPセッションにインストールされるまで、攻撃者は「supportedsaslmechanisms」属性応答の送信値を変更し、利用可能なSASLメカニズムのリストをダウングレードして、最も安全なメカニズムのみを含めることができます。このタイプの攻撃を検出するために、クライアントは、データの整合性サービスがLDAPセッションにインストールされる前後の両方で、サーバーが利用可能にするSASLメカニズムを取得する場合があります。クライアントが、整合性保護リスト（データ整合性サービスがインストールされた後に取得したリスト）に、以前に取得したリストのメカニズムよりも強力なメカニズムが含まれていることをクライアントが見つけた場合、クライアントは、以前に取得したリストが攻撃者によって変更されたと想定する必要があります。この状況では、クライアントが基礎となる輸送接続を閉じてから再接続してセッションを再確立することをお勧めします。
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.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タイプレジストリを更新して、このドキュメントと[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 Bind認証メソッドレジストリを更新して、このドキュメントと[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 prefixesの決定的な技術仕様を提供することを示しています。
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）ワーキンググループのアクセス、検索、インデックス作成の製品でした。RFC 2829およびRFC 2830は、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。、「インターネットプロトコル」、STD 5、RFC 791、1981年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 3490、2003年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プロファイル」、RFC 4013、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.
[RFC4346] Dierks、T。およびE. Rescorla、「TLSプロトコルバージョン1.1」、RFC 4346、2006年3月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A.、ed。K. Zeilenga編、「Simple Authentication and Security Layer（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。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：ディレクトリ情報モデル」、RFC 4512、2006年6月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、ed。、「Lightweight Directory Access Protocol（LDAP）：著名な名前の文字列表現」、RFC 4514、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517] Legg、S.、ed。、「Lightweight Directory Access Protocol（LDAP）：構文と一致するルール」、RFC 4517、2006年6月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、ed。、「Lightweight Directory Access Protocol（LDAP）：ユーザーアプリケーションのスキーマ」、RFC 4519、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。、「Internet Assigned Numbers Authority（IANA）Lightweight Directory Access Protocol（LDAP）の考慮事項」、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 Standard、バージョン3.2.0」は、「Unicode Standard、バージョン3.0」（Reading、MA、Addison-Wesley、2000。ISBN0-201-61633-5）で定義されています。「Unicode Standard Annex＃27：Unicode 3.1」（http://www.unicode.org/reports/tr27/）および「Unicode Standard Annex＃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.
[Plain] 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 4301、2005年12月。
[RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505, June 2006.
[RFC4505] Zeilenga、K。、「匿名SASLメカニズム」、RFC 4505、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で操作を実行できるリクエスト」。サーバーがそのような表現に利用できる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 credential forms. Note that an authentication mechanism may constrain the form of authentication identities used with it.
認証資格情報には多くの形式があります。使用されるフォームは、当事者によって交渉された特定の認証メカニズムに依存します。X.509証明書、Kerberosチケット、および単純なIDとパスワードのペアはすべて、認証資格情報の例です。認証メカニズムは、使用される認証アイデンティティの形式を制約する場合があることに注意してください。
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".
承認IDは、1つのアクセス制御要因の1つです。操作を実行することを要求するのは、ユーザーまたは他のエンティティの名前です。アクセス制御ポリシーは、多くの場合、承認のアイデンティティの観点から表現されます。たとえば、「エンティティ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により、クライアントは、クライアントの資格情報によって主張された認証IDとは異なる認証IDを指定できます。これにより、プロキシサーバーなどのエージェントは独自の資格情報を使用して認証することができますが、プロキシングしているアイデンティティのアクセス権限を要求します[RFC4422]。また、TLSのようなサービスによって提供される認証IDの形式は、サーバーのアクセス制御ポリシーを表現するために使用される承認IDに対応していないため、サーバー固有のマッピングを実行する必要があります。サーバーがクライアントが提供する認証資格情報から承認IDを構成して検証する方法は、実装固有です。
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.
- RFC 2251は、単純なバインド法を使用して匿名認証を実行する必要があると述べています。この仕様は、Simple Bindメソッドの匿名認証メカニズムを定義し、それをサポートするためにすべての適合実装が必要です。匿名認証と認証状態を生成する他の認証メカニズムも、実装を適合して実装および使用できます。
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認証メカニズムを引き続き文書化しています。
- 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.
- すべてのSASL認証メカニズムは、LDAP内で明示的に許可されています。具体的には、これはSASL匿名およびSASLプレーンメカニズムがLDAP内での使用を妨げられなくなったことを意味します。
- 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_RSA_WITH_3DES_EDE_CBC_SHA CipherSuiteをサポートする必要があり、TLS_DHE_DSS_WITH_3DES_EDE_EDE_CBC_SHA CIPHERSUITEを引き続きサポートする必要があります。
- 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.
- サーバーIDのチェックアルゴリズムを大幅に更新して、完全かつ堅牢であることを確認しました。特に、sumbercaltnameおよびsubjectNameフィールドでのすべての関連する値の使用は、アルゴリズムでカバーされ、一致するルールは各タイプの値に対して指定されます。マッピングが安全な方法で実行されるときに、マッピング（派生）フォームのサーバーIDが使用されるようになりました。
- 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の確立後にサーバー機能に関する情報を常に更新する必要がなくなりました。これは、安全なメカニズムを通じてこの情報が得られた状況を可能にするためです。
- 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
Roger Harrison Novell、Inc。1800 S. Novell Place Provo、UT 84606 USA
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。