[要約] RFC 2829は、LDAPの認証方法に関する標準仕様であり、LDAPサーバーとクライアント間の認証プロセスを定義しています。このRFCの目的は、LDAPのセキュリティを向上させ、信頼性のある認証メカニズムを提供することです。
Network Working Group M. Wahl
Request for Comments: 2829 Sun Microsystems, Inc.
Category: Standards Track H. Alvestrand
EDB Maxware
J. Hodges
Oblix, Inc.
R. Morgan
University of Washington
May 2000
Authentication Methods for LDAP
LDAPの認証方法
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations.
このドキュメントは、LDAP [1]の実装で必要および推奨されるセキュリティメカニズムの特定の組み合わせを指定します。
LDAP version 3 is a powerful access protocol for directories.
LDAPバージョン3は、ディレクトリ用の強力なアクセスプロトコルです。
It offers means of searching, fetching and manipulating directory content, and ways to access a rich set of security functions.
ディレクトリコンテンツの検索、フェッチ、および操作の手段、および豊富なセキュリティ機能にアクセスする方法を提供します。
In order to function for the best of the Internet, it is vital that these security functions be interoperable; therefore there has to be a minimum subset of security functions that is common to all implementations that claim LDAPv3 conformance.
インターネットの最高の機能に機能するためには、これらのセキュリティ機能が相互運用可能であることが重要です。したがって、LDAPV3の適合性を主張するすべての実装に共通するセキュリティ関数の最小サブセットが必要です。
Basic threats to an LDAP directory service include:
LDAPディレクトリサービスに対する基本的な脅威は次のとおりです。
(1) Unauthorized access to data via data-fetching operations, (2) Unauthorized access to reusable client authentication information by monitoring others' access,
(1) データフェッチ操作を介したデータへの不正アクセス、（2）他の人のアクセスを監視することにより、再利用可能なクライアント認証情報への不正アクセス、
(3) Unauthorized access to data by monitoring others' access,
(3) 他の人のアクセスを監視することにより、データへの不正アクセス、
(4) Unauthorized modification of data,
(4) データの不正な変更、
(5) Unauthorized modification of configuration,
(5) 構成の不正な変更、
(6) Unauthorized or excessive use of resources (denial of service), and
(6) リソースの不正または過度の使用（サービスの拒否）、および
(7) Spoofing of directory: Tricking a client into believing that information came from the directory when in fact it did not, either by modifying data in transit or misdirecting the client's connection.
(7) ディレクトリのスプーフィング：クライアントは、実際には、輸送中のデータを変更するか、クライアントの接続を誤って指定することによって、情報がディレクトリから来たと信じていると信じています。
Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), (3) and (7) are due to hostile agents on the path between client and server, or posing as a server.
脅威（1）、（4）、（5）、および（6）は敵対的なクライアントによるものです。脅威（2）、（3）、および（7）は、クライアントとサーバーの間のパス上の敵対的なエージェント、またはサーバーとしてのポーズによるものです。
The LDAP protocol suite can be protected with the following security mechanisms:
LDAPプロトコルスイートは、次のセキュリティメカニズムで保護できます。
(1) Client authentication by means of the SASL [2] mechanism set, possibly backed by the TLS credentials exchange mechanism,
(1) SASL [2]メカニズムセットによるクライアント認証、おそらくTLS資格情報交換メカニズムに裏付けられている可能性があります。
(2) Client authorization by means of access control based on the requestor's authenticated identity,
(2) 要求者の認証されたアイデンティティに基づいたアクセス制御によるクライアントの承認、
(3) Data integrity protection by means of the TLS protocol or data-integrity SASL mechanisms,
(3) TLSプロトコルまたはデータ統合SASLメカニズムによるデータ整合性保護、
(4) Protection against snooping by means of the TLS protocol or data-encrypting SASL mechanisms,
(4) TLSプロトコルまたはデータ暗号化SASLメカニズムによるスヌーピングに対する保護、
(5) Resource limitation by means of administrative limits on service controls, and
(5) サービスコントロールの管理制限によるリソース制限、および
(6) Server authentication by means of the TLS protocol or SASL mechanism.
(6) TLSプロトコルまたはSASLメカニズムによるサーバー認証。
At the moment, imposition of access controls is done by means outside the scope of the LDAP protocol.
現時点では、アクセス制御の賦課は、LDAPプロトコルの範囲外の手段によって行われています。
In this document, the term "user" represents any application which is an LDAP client using the directory to retrieve or store information.
このドキュメントでは、「ユーザー」という用語は、ディレクトリを使用して情報を取得または保存するLDAPクライアントであるアプリケーションを表します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [3]に記載されているように解釈される。
The following scenarios are typical for LDAP directories on the Internet, and have different security requirements. (In the following, "sensitive" means data that will cause real damage to the owner if revealed; there may be data that is protected but not sensitive). This is not intended to be a comprehensive list, other scenarios are possible, especially on physically protected networks.
次のシナリオは、インターネット上のLDAPディレクトリに典型的なものであり、さまざまなセキュリティ要件があります。（以下では、「敏感」とは、明らかにされた場合、所有者に本当の損傷を引き起こすデータを意味します。保護されているが感度ではないデータが存在する可能性があります）。これは包括的なリストになることを意図したものではなく、特に物理的に保護されたネットワークでは、他のシナリオが可能です。
(1) A read-only directory, containing no sensitive data, accessible to "anyone", and TCP connection hijacking or IP spoofing is not a problem. This directory requires no security functions except administrative service limits.
(1) 「誰でも」にアクセスできる機密データが含まれていない読み取り専用ディレクトリ、およびTCP接続ハイジャックまたはIPスプーフィングは問題ではありません。このディレクトリには、管理サービスの制限以外のセキュリティ機能は必要ありません。
(2) A read-only directory containing no sensitive data; read access is granted based on identity. TCP connection hijacking is not currently a problem. This scenario requires a secure authentication function.
(2) 機密データがない読み取り専用ディレクトリ。読み取りアクセスはIDに基づいて付与されます。TCP接続ハイジャックは現在問題ではありません。このシナリオには、安全な認証関数が必要です。
(3) A read-only directory containing no sensitive data; and the client needs to ensure that the directory data is authenticated by the server and not modified while being returned from the server.
(3) 機密データがない読み取り専用ディレクトリ。また、クライアントは、ディレクトリデータがサーバーから認証され、サーバーから返されている間に変更されていないことを確認する必要があります。
(4) A read-write directory, containing no sensitive data; read access is available to "anyone", update access to properly authorized persons. TCP connection hijacking is not currently a problem. This scenario requires a secure authentication function.
(4) 機密データが含まれていない読み取りワイトディレクトリ。読み取りアクセスは、「誰でも」、適切に許可された人へのアクセスを更新します。TCP接続ハイジャックは現在問題ではありません。このシナリオには、安全な認証関数が必要です。
(5) A directory containing sensitive data. This scenario requires session confidentiality protection AND secure authentication.
(5) 機密データを含むディレクトリ。このシナリオには、セッションの機密保護と安全な認証が必要です。
This section defines basic terms, concepts, and interrelationships regarding authentication, authorization, credentials, and identity. These concepts are used in describing how various security approaches are utilized in client authentication and authorization.
このセクションでは、認証、承認、資格情報、およびアイデンティティに関する基本的な用語、概念、および相互関係を定義します。これらの概念は、クライアントの認証と承認でさまざまなセキュリティアプローチがどのように利用されるかを説明する際に使用されます。
An access control policy is a set of rules defining the protection of resources, generally in terms of the capabilities of persons or other entities accessing those resources. A common expression of an access control policy is an access control list. Security objects and mechanisms, such as those described here, enable the expression of access control policies and their enforcement. Access control policies are typically expressed in terms of access control attributes as described below.
アクセス制御ポリシーは、一般に、それらのリソースにアクセスする人または他のエンティティの機能の観点から、リソースの保護を定義する一連のルールです。アクセス制御ポリシーの一般的な表現は、アクセス制御リストです。ここで説明するようなセキュリティオブジェクトとメカニズムは、アクセス制御ポリシーの表現とその施行を可能にします。通常、アクセス制御ポリシーは、以下に説明するように、アクセス制御属性の観点から表されます。
A request, when it is being processed by a server, may be associated with a wide variety of security-related factors (section 4.2 of [1]). The server uses these factors to determine whether and how to process the request. These are called access control factors (ACFs). They might include source IP address, encryption strength, the type of operation being requested, time of day, etc. Some factors may be specific to the request itself, others may be associated with the connection via which the request is transmitted, others (e.g. time of day) may be "environmental".
リクエストは、サーバーによって処理されている場合、さまざまなセキュリティ関連の要因に関連付けられている可能性があります（[1]のセクション4.2）。サーバーはこれらの要因を使用して、リクエストの処理方法と方法を決定します。これらは、アクセス制御係数（ACF）と呼ばれます。ソースIPアドレス、暗号化強度、要求される操作の種類、時刻などが含まれる場合があります。一部の要因は、リクエスト自体に固有の場合があり、他の要因は要求が送信される接続に関連付けられている場合があります。時刻）は「環境」かもしれません。
Access control policies are expressed in terms of access control factors. E.g., a request having ACFs i,j,k can perform operation Y on resource Z. The set of ACFs that a server makes available for such expressions is implementation-specific.
アクセス制御ポリシーは、アクセス制御要因の観点から表されます。たとえば、ACFS I、J、KがリソースZで操作Yを実行できます。サーバーがそのような表現で利用できる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 an association with the other party (typically a server). Authentication is the process of generating, transmitting, and verifying these credentials and thus the identity they assert. An authentication identity is the name presented in a credential.
認証資格情報は、ある当事者が別の当事者から提供する証拠であり、供給者（例：ユーザー）の身元（通常はサーバー）との関連を確立しようとしていることを主張します。認証とは、これらの資格情報を生成、送信、および検証するプロセス、したがって彼らが主張するアイデンティティです。認証アイデンティティは、資格情報に表示される名前です。
There are many forms of authentication credentials -- the form used depends upon the particular authentication mechanism negotiated by the parties. For example: X.509 certificates, Kerberos tickets, simple identity and password pairs. Note that an authentication mechanism may constrain the form of authentication identities used with it.
多くの形式には認証資格情報があります。使用されるフォームは、当事者によって交渉された特定の認証メカニズムに依存します。たとえば、X.509証明書、Kerberosチケット、シンプルな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; e.g., entity X can perform operation Y on resource Z.
承認IDは、1つのアクセス制御要因の1つです。操作を実行することを要求するのは、ユーザーまたは他のエンティティの名前です。アクセス制御ポリシーは、多くの場合、承認のアイデンティティの観点から表現されます。たとえば、エンティティXはリソースZで操作Yを実行できます。
The authorization identity bound to an association is often exactly the same as the authentication identity presented by the client, but it may be different. SASL allows clients to specify an authorization identity distinct from the authentication identity asserted by the client's credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying [2]. Also, the form of authentication identity supplied by a service like TLS may not correspond to the authorization identities used to express a server's access control policy, requiring a server-specific mapping to be done. The method by which a server composes and validates an authorization identity from the authentication credentials supplied by a client is implementation-specific.
協会に縛られた認証アイデンティティは、多くの場合、クライアントが提示した認証IDとまったく同じですが、異なる場合があります。SASLにより、クライアントは、クライアントの資格情報によって主張された認証IDとは異なる認証IDを指定できます。これにより、プロキシサーバーなどのエージェントは、独自の資格情報を使用して認証することができますが、彼らがプロキシしているアイデンティティのアクセス権限を要求します[2]。また、TLSのようなサービスによって提供される認証IDの形式は、サーバーのアクセス制御ポリシーを表現するために使用される承認アイデンティティに対応していない場合があり、サーバー固有のマッピングを行う必要があります。サーバーがクライアントが提供する認証資格情報から認証IDを構成および検証する方法は、実装固有です。
It is clear that allowing any implementation, faced with the above requirements, to pick and choose among the possible alternatives is not a strategy that is likely to lead to interoperability. In the absence of mandates, clients will be written that do not support any security function supported by the server, or worse, support only mechanisms like cleartext passwords that provide clearly inadequate security.
上記の要件に直面した実装を許可することで、可能な選択肢の中から選択して選択することは、相互運用性につながる可能性が高い戦略ではないことは明らかです。マンデートがない場合、サーバーがサポートするセキュリティ機能をサポートしていないクライアントは、またはさらに悪いことに、明らかに不十分なセキュリティを提供するクリアテキストパスワードのようなメカニズムのみをサポートします。
Active intermediary attacks are the most difficult for an attacker to perform, and for an implementation to protect against. Methods that protect only against hostile client and passive eavesdropping attacks are useful in situations where the cost of protection against active intermediary attacks is not justified based on the perceived risk of active intermediary attacks.
アクティブな仲介攻撃は、攻撃者が実行するのが最も困難です。敵対的なクライアントと受動的な盗聴攻撃からのみ保護する方法は、積極的な仲介攻撃に対する保護コストが積極的な仲介攻撃の認識されたリスクに基づいて正当化されない状況で有用です。
Given the presence of the Directory, there is a strong desire to see mechanisms where identities take the form of a Distinguished Name and authentication data can be stored in the directory; this means that either this data is useless for faking authentication (like the Unix "/etc/passwd" file format used to be), or its content is never passed across the wire unprotected - that is, it's either updated outside the protocol or it is only updated in sessions well protected against snooping. It is also desirable to allow authentication methods to carry authorization identities based on existing forms of user identities for backwards compatibility with non-LDAP-based authentication services.
ディレクトリの存在を考えると、アイデンティティが著名な名前と認証データをディレクトリに保存できるメカニズムを確認する強い欲求があります。つまり、このデータは、認証を偽造するのに役に立たない（以前はunix "/etc/passwd"ファイル形式など）、またはそのコンテンツがワイヤー全体に渡されないことを意味します。スヌーピングに対して十分に保護されているセッションでのみ更新されます。また、非LDAPベースの認証サービスとの逆方向の互換性のためのユーザーIDの既存のフォームに基づいて、認証方法が認証識別を担当できるようにすることも望ましいです。
Therefore, the following implementation conformance requirements are in place:
したがって、次の実装適合要件が整っています。
(1) For a read-only, public directory, anonymous authentication, described in section 5, can be used.
(1) 読み取り専用の場合、セクション5で説明されているパブリックディレクトリ、匿名認証を使用できます。
(2) Implementations providing password-based authenticated access MUST support authentication using the DIGEST-MD5 SASL mechanism [4], as described in section 6.1. This provides client authentication with protection against passive eavesdropping attacks, but does not provide protection against active intermediary attacks.
(2) パスワードベースの認証されたアクセスを提供する実装は、セクション6.1で説明されているように、Digest-MD5 SASLメカニズム[4]を使用した認証をサポートする必要があります。これにより、クライアント認証は受動的な盗聴攻撃に対する保護を提供しますが、積極的な仲介攻撃に対する保護を提供しません。
(3) For a directory needing session protection and authentication, the Start TLS extended operation [5], and either the simple authentication choice or the SASL EXTERNAL mechanism, are to be used together. Implementations SHOULD support authentication with a password as described in section 6.2, and SHOULD support authentication with a certificate as described in section 7.1. Together, these can provide integrity and disclosure protection of transmitted data, and authentication of client and server, including protection against active intermediary attacks.
(3) セッションの保護と認証を必要とするディレクトリの場合、Start TLS拡張操作[5]、および単純な認証選択またはSASL外部メカニズムのいずれかを一緒に使用します。実装は、セクション6.2で説明されているパスワードで認証をサポートする必要があり、セクション7.1で説明されているように、証明書の認証をサポートする必要があります。一緒に、これらは送信されたデータの整合性と開示保護、およびアクティブな仲介攻撃に対する保護を含むクライアントとサーバーの認証を提供できます。
If TLS is negotiated, the client MUST discard all information about the server fetched prior to the TLS negotiation. In particular, the value of supportedSASLMechanisms MAY be different after TLS has been negotiated (specifically, the EXTERNAL mechanism or the proposed PLAIN mechanism are likely to only be listed after a TLS negotiation has been performed).
TLSがネゴシエートされた場合、クライアントはTLS交渉の前にフェッチされたサーバーに関するすべての情報を破棄する必要があります。特に、TLSが交渉された後、サポートされたサスルメカニズムの価値は異なる場合があります（具体的には、外部メカニズムまたは提案されたプレーンメカニズムは、TLS交渉が実行された後にのみリストされる可能性があります）。
If a SASL security layer is negotiated, the client MUST discard all information about the server fetched prior to SASL. In particular, if the client is configured to support multiple SASL mechanisms, it SHOULD fetch supportedSASLMechanisms both before and after the SASL security layer is negotiated and verify that the value has not changed after the SASL security layer was negotiated. This detects active attacks which remove supported SASL mechanisms from the supportedSASLMechanisms list, and allows the client to ensure that it is using the best mechanism supported by both client and server (additionally, this is a SHOULD to allow for environments where the supported SASL mechanisms list is provided to the client through a different trusted source, e.g. as part of a digitally signed object).
SASLセキュリティレイヤーがネゴシエートされた場合、クライアントはSASLの前にフェッチされたサーバーに関するすべての情報を破棄する必要があります。特に、クライアントが複数のSASLメカニズムをサポートするように構成されている場合、SASLセキュリティレイヤーがネゴシエートされた後、SASLセキュリティ層が交渉された後に値が変更されていないことを確認する前後の両方でサポートされたSaslmechanismを取得する必要があります。これにより、サポートされているSASLメカニズムをサポートされているSASLメカニズムリストから除去するアクティブな攻撃が検出され、クライアントがクライアントとサーバーの両方でサポートされている最良のメカニズムを使用できるようにします（さらに、これは、サポートされているSASLメカニズムリストが環境を可能にする必要があります。別の信頼できるソースを介してクライアントに提供されます。たとえば、デジタル署名されたオブジェクトの一部として）。
Directory operations which modify entries or access protected attributes or entries generally require client authentication. Clients which do not intend to perform any of these operations typically use anonymous authentication.
エントリまたはアクセス保護された属性またはエントリにアクセスするディレクトリ操作は、通常、クライアント認証が必要です。これらの操作のいずれかを実行するつもりはないクライアントは、通常、匿名認証を使用します。
LDAP implementations MUST support anonymous authentication, as defined in section 5.1.
LDAPの実装は、セクション5.1で定義されているように、匿名認証をサポートする必要があります。
LDAP implementations MAY support anonymous authentication with TLS, as defined in section 5.2.
LDAP実装は、セクション5.2で定義されているように、TLSを使用した匿名認証をサポートする場合があります。
While there MAY be access control restrictions to prevent access to directory entries, an LDAP server SHOULD allow an anonymously-bound client to retrieve the supportedSASLMechanisms attribute of the root DSE.
ディレクトリエントリへのアクセスを防ぐためのアクセス制御制限がある場合がありますが、LDAPサーバーは、匿名でバインドされたクライアントがルートDSEのsupportssaslmechanisms属性を取得できるようにする必要があります。
An LDAP server MAY use other information about the client provided by the lower layers or external means to grant or deny access even to anonymously authenticated clients.
LDAPサーバーは、匿名で認証されたクライアントにもアクセスを許可または拒否するために、下層または外部手段によって提供されるクライアントに関する他の情報を使用する場合があります。
An LDAP client which has not successfully completed a bind operation on a connection is anonymously authenticated.
接続のバインド操作を正常に完了していないLDAPクライアントは、匿名で認証されています。
An LDAP client MAY also specify anonymous authentication in a bind request by using a zero-length OCTET STRING with the simple authentication choice.
LDAPクライアントは、単純な認証選択を備えたゼロの長さのオクテット文字列を使用して、バインドリクエストで匿名認証を指定することもできます。
An LDAP client MAY use the Start TLS operation [5] to negotiate the use of TLS security [6]. If the client has not bound beforehand, then until the client uses the EXTERNAL SASL mechanism to negotiate the recognition of the client's certificate, the client is anonymously authenticated.
LDAPクライアントは、Start TLS操作[5]を使用して、TLSセキュリティ[6]の使用を交渉できます。クライアントが事前に拘束されていない場合、クライアントが外部SASLメカニズムを使用してクライアントの証明書の認識を交渉するまで、クライアントは匿名で認証されます。
Recommendations on TLS ciphersuites are given in section 10.
TLS暗号に関する推奨事項は、セクション10に記載されています。
An LDAP server which requests that clients provide their certificate during TLS negotiation MAY use a local security policy to determine whether to successfully complete TLS negotiation if the client did not present a certificate which could be validated.
TLS交渉中にクライアントが証明書を提供することを要求するLDAPサーバーは、ローカルセキュリティポリシーを使用して、クライアントが検証できる証明書を提示しなかった場合にTLS交渉を正常に完了するかどうかを判断することができます。
LDAP implementations MUST support authentication with a password using the DIGEST-MD5 SASL mechanism for password protection, as defined in section 6.1.
LDAPの実装は、セクション6.1で定義されているように、パスワード保護のためにDigest-MD5 SASLメカニズムを使用したパスワードで認証をサポートする必要があります。
LDAP implementations SHOULD support authentication with the "simple" password choice when the connection is protected against eavesdropping using TLS, as defined in section 6.2.
LDAPの実装は、セクション6.2で定義されているように、TLSを使用した盗聴に対して接続が保護されている場合、「単純な」パスワード選択で認証をサポートする必要があります。
An LDAP client MAY determine whether the server supports this mechanism by performing a search request on the root DSE, requesting the supportedSASLMechanisms attribute, and checking whether the string "DIGEST-MD5" is present as a value of this attribute.
LDAPクライアントは、ルートDSEで検索要求を実行し、supportedSaslmechanisms属性を要求し、文字列「Digest-MD5」がこの属性の値として存在するかどうかを確認することにより、サーバーがこのメカニズムをサポートするかどうかを判断できます。
In the first stage of authentication, when the client is performing an "initial authentication" as defined in section 2.1 of [4], the client sends a bind request in which the version number is 3, the authentication choice is sasl, the sasl mechanism name is "DIGEST-MD5", and the credentials are absent. The client then waits for a response from the server to this request.
認証の最初の段階では、クライアントが[4]のセクション2.1で定義されている「初期認証」を実行している場合、クライアントはバージョン番号が3のバインド要求を送信します。認証選択はSASL、SASLメカニズムです。名前は「Digest-MD5」であり、資格情報はありません。その後、クライアントはサーバーからこのリクエストへの応答を待ちます。
The server will respond with a bind response in which the resultCode is saslBindInProgress, and the serverSaslCreds field is present. The contents of this field is a string defined by "digest-challenge" in section 2.1.1 of [4]. The server SHOULD include a realm indication and MUST indicate support for UTF-8.
サーバーは、結果コードがsaslbindinprogressであるバインド応答で応答し、ServersAslcredsフィールドが存在します。このフィールドの内容は、[4]のセクション2.1.1の「ダイジェストチャレンジ」によって定義される文字列です。サーバーには領域を含める必要があり、UTF-8のサポートを示す必要があります。
The client will send a bind request with a distinct message id, in which the version number is 3, the authentication choice is sasl, the sasl mechanism name is "DIGEST-MD5", and the credentials contain the string defined by "digest-response" in section 2.1.2 of [4]. The serv-type is "ldap".
クライアントは、バージョン番号が3の個別のメッセージIDを使用してバインドリクエストを送信します。認証選択はSASL、SASLメカニズム名は「ダイジェスト-MD5」、資格情報には「Digest-Response」で定義された文字列が含まれます「[4]のセクション2.1.2で。サーブタイプは「LDAP」です。
The server will respond with a bind response in which the resultCode is either success, or an error indication. If the authentication is successful and the server does not support subsequent authentication, then the credentials field is absent. If the authentication is successful and the server supports subsequent authentication, then the credentials field contains the string defined by "response-auth" in section 2.1.3 of [4]. Support for subsequent authentication is OPTIONAL in clients and servers.
サーバーは、結果コードが成功またはエラー表示のいずれかであるバインド応答で応答します。認証が成功し、サーバーが後続の認証をサポートしていない場合、資格情報フィールドはありません。認証が成功し、サーバーが後続の認証をサポートする場合、[4]のセクション2.1.3の「Response-Auth」で定義された文字列が含まれます。後続の認証のサポートは、クライアントとサーバーでオプションです。
A user who has a directory entry containing a userPassword attribute MAY authenticate to the directory by performing a simple password bind sequence following the negotiation of a TLS ciphersuite providing connection confidentiality [6].
ユーザーパスワード属性を含むディレクトリエントリを持っているユーザーは、接続の機密性を提供するTLS ciphersuiteの交渉に続いて、シンプルなパスワードバインドシーケンスを実行することにより、ディレクトリに認証できます[6]。
The client will use the Start TLS operation [5] to negotiate the use of TLS security [6] on the connection to the LDAP server. The client need not have bound to the directory beforehand.
クライアントは、Start TLS操作[5]を使用して、LDAPサーバーへの接続でTLSセキュリティ[6]の使用をネゴシエートします。クライアントは、事前にディレクトリにバインドする必要はありません。
For this authentication procedure to be successful, the client and server MUST negotiate a ciphersuite which contains a bulk encryption algorithm of appropriate strength. Recommendations on cipher suites are given in section 10.
この認証手順を成功させるには、クライアントとサーバーは、適切な強度のバルク暗号化アルゴリズムを含む暗号項を交渉する必要があります。暗号スイートに関する推奨事項は、セクション10に記載されています。
Following the successful completion of TLS negotiation, the client MUST send an LDAP bind request with the version number of 3, the name field containing the name of the user's entry, and the "simple" authentication choice, containing a password.
TLS交渉が正常に完了した後、クライアントはバージョン番号3、ユーザーのエントリの名前を含む名前フィールド、およびパスワードを含む「単純な」認証選択でLDAPバインドリクエストを送信する必要があります。
The server will, for each value of the userPassword attribute in the named user's entry, compare these for case-sensitive equality with the client's presented password. If there is a match, then the server will respond with resultCode success, otherwise the server will respond with resultCode invalidCredentials.
サーバーは、指定されたユーザーのエントリにあるuserPassword属性の各値に対して、ケースに敏感な平等についてこれらをクライアントの提示されたパスワードと比較します。一致している場合、サーバーは結果コードの成功で応答します。そうしないと、サーバーは結果のコードが無効な場合に応答します。
It is also possible, following the negotiation of TLS, to perform a SASL authentication which does not involve the exchange of plaintext reusable passwords. In this case the client and server need not negotiate a ciphersuite which provides confidentiality if the only service required is data integrity.
TLSの交渉に続いて、プレーンテキストの再利用可能なパスワードの交換を伴わないSASL認証を実行することも可能です。この場合、クライアントとサーバーは、必要なサービスがデータの整合性である場合、機密性を提供するCiphersuiteを交渉する必要はありません。
LDAP implementations SHOULD support authentication via a client certificate in TLS, as defined in section 7.1.
LDAPの実装は、セクション7.1で定義されているように、TLSのクライアント証明書を介して認証をサポートする必要があります。
A user who has a public/private key pair in which the public key has been signed by a Certification Authority may use this key pair to authenticate to the directory server if the user's certificate is requested by the server. The user's certificate subject field SHOULD be the name of the user's directory entry, and the Certification Authority must be sufficiently trusted by the directory server to have issued the certificate in order that the server can process the certificate. The means by which servers validate certificate paths is outside the scope of this document.
公開キーが認証機関によって署名されたパブリック/プライベートキーペアを持っているユーザーは、ユーザーの証明書がサーバーによって要求された場合、このキーペアを使用してディレクトリサーバーに認証することができます。ユーザーの証明書の件名フィールドは、ユーザーのディレクトリエントリの名前である必要があり、認証機関は、サーバーが証明書を処理できるように証明書を発行するためにディレクトリサーバーによって十分に信頼されている必要があります。サーバーが証明書パスを検証する手段は、このドキュメントの範囲外にあります。
A server MAY support mappings for certificates in which the subject field name is different from the name of the user's directory entry. A server which supports mappings of names MUST be capable of being configured to support certificates for which no mapping is required.
サーバーは、サブジェクトのフィールド名がユーザーのディレクトリエントリの名前と異なる証明書のマッピングをサポートできます。名前のマッピングをサポートするサーバーは、マッピングが不要な証明書をサポートするように構成できる必要があります。
The client will use the Start TLS operation [5] to negotiate the use of TLS security [6] on the connection to the LDAP server. The client need not have bound to the directory beforehand.
クライアントは、Start TLS操作[5]を使用して、LDAPサーバーへの接続でTLSセキュリティ[6]の使用をネゴシエートします。クライアントは、事前にディレクトリにバインドする必要はありません。
In the TLS negotiation, the server MUST request a certificate. The client will provide its certificate to the server, and MUST perform a private key-based encryption, proving it has the private key associated with the certificate.
TLS交渉では、サーバーは証明書を要求する必要があります。クライアントはその証明書をサーバーに提供し、秘密キーベースの暗号化を実行する必要があり、証明書に関連付けられた秘密鍵があることを証明する必要があります。
As deployments will require protection of sensitive data in transit, the client and server MUST negotiate a ciphersuite which contains a bulk encryption algorithm of appropriate strength. Recommendations of cipher suites are given in section 10.
展開には輸送中の機密データの保護が必要なため、クライアントとサーバーは、適切な強度のバルク暗号化アルゴリズムを含む暗号性を交渉する必要があります。暗号スイートの推奨事項は、セクション10に記載されています。
The server MUST verify that the client's certificate is valid. The server will normally check that the certificate is issued by a known CA, and that none of the certificates on the client's certificate chain are invalid or revoked. There are several procedures by which the server can perform these checks.
サーバーは、クライアントの証明書が有効であることを確認する必要があります。サーバーは通常、証明書が既知のCAによって発行されていること、およびクライアントの証明書チェーン上の証明書が無効または取り消されていないことを確認します。サーバーがこれらのチェックを実行できる手順がいくつかあります。
Following the successful completion of TLS negotiation, the client will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
TLS交渉が正常に完了した後、クライアントはSASLの「外部」メカニズムを使用してLDAPバインドリクエストを送信します。
The LDAP "simple" authentication choice is not suitable for authentication on the Internet where there is no network or transport layer confidentiality.
LDAPの「単純な」認証の選択は、ネットワークまたは輸送層の機密性がないインターネット上の認証には適していません。
As LDAP includes native anonymous and plaintext authentication methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used with LDAP. If an authorization identity of a form different from a DN is requested by the client, a mechanism that protects the password in transit SHOULD be used.
LDAPにはネイティブの匿名およびプレーンテキスト認証方法が含まれているため、「匿名」および「プレーン」SASLメカニズムはLDAPで使用されません。クライアントがDNとは異なるフォームの認可IDがクライアントによって要求される場合、輸送中のパスワードを保護するメカニズムを使用する必要があります。
The following SASL-based mechanisms are not considered in this document: KERBEROS_V4, GSSAPI and SKEY.
このドキュメントでは、次のSASLベースのメカニズムは考慮されていません：Kerberos_V4、GSSAPI、およびSKEY。
The "EXTERNAL" SASL mechanism can be used to request the LDAP server make use of security credentials exchanged by a lower layer. If a TLS session has not been established between the client and server prior to making the SASL EXTERNAL Bind request and there is no other external source of authentication credentials (e.g. IP-level security [8]), or if, during the process of establishing the TLS session, the server did not request the client's authentication credentials, the SASL EXTERNAL bind MUST fail with a result code of inappropriateAuthentication. Any client authentication and authorization state of the LDAP association is lost, so the LDAP association is in an anonymous state after the failure.
「外部」SASLメカニズムを使用して、LDAPサーバーに下層層で交換されたセキュリティ資格情報を使用することを要求できます。SASL外部バインドリクエストを行う前にクライアントとサーバーの間にTLSセッションが確立されていない場合、認証資格情報の他の外部ソース（例：IPレベルセキュリティ[8]）、または、確立中に、TLSセッションでは、サーバーはクライアントの認証資格情報を要求しませんでした。SASL外部バインドは、不適切な認証の結果コードで失敗する必要があります。LDAP協会のクライアント認証と承認の状態は失われているため、LDAP協会は障害後に匿名の状態にあります。
The authorization identity is carried as part of the SASL credentials field in the LDAP Bind request and response.
認証IDは、LDAPバインドリクエストと応答のSASL資格情報フィールドの一部として運ばれます。
When the "EXTERNAL" mechanism is being negotiated, if the credentials field is present, it contains an authorization identity of the authzId form described below.
「外部」メカニズムがネゴシエートされている場合、資格情報フィールドが存在する場合、以下に説明するauthzidフォームの承認アイデンティティが含まれています。
Other mechanisms define the location of the authorization identity in the credentials field.
他のメカニズムは、資格情報のフィールドにおける承認IDの位置を定義します。
The authorization identity is a string in the UTF-8 character set, corresponding to the following ABNF [7]:
認証IDは、次のABNF [7]に対応するUTF-8文字セットの文字列です。
; Specific predefined authorization (authz) id schemes are ; defined below -- new schemes may be defined in the future.
;特定の事前定義承認（authz）IDスキームは次のとおりです。以下に定義する - 新しいスキームは将来定義される場合があります。
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
dn = utf8string ; with syntax defined in RFC 2253
; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
A utf8string is defined to be the UTF-8 encoding of one or more ISO 10646 characters.
UTF8STRINGは、1つ以上のISO 10646文字のUTF-8エンコードであると定義されています。
All servers which support the storage of authentication credentials, such as passwords or certificates, in the directory MUST support the dnAuthzId choice.
ディレクトリ内のパスワードや証明書などの認証資格情報のストレージをサポートするすべてのサーバーは、Dnauthzidの選択をサポートする必要があります。
The uAuthzId choice allows for compatibility with client applications which wish to authenticate to a local directory but do not know their own Distinguished Name or have a directory entry. The format of the string is defined as only a sequence of UTF-8 encoded ISO 10646 characters, and further interpretation is subject to prior agreement between the client and server.
uauthzidの選択により、ローカルディレクトリに認証したいが、独自の著名な名前を知らないか、ディレクトリエントリがあるクライアントアプリケーションと互換性があります。文字列の形式は、UTF-8エンコードされたISO 10646文字のシーケンスのみとして定義され、さらなる解釈はクライアントとサーバーの間の事前の合意の対象となります。
For example, the userid could identify a user of a specific directory service, or be a login name or the local-part of an RFC 822 email address. In general a uAuthzId MUST NOT be assumed to be globally unique.
たとえば、ユーザーIDは、特定のディレクトリサービスのユーザーを識別したり、RFC 822メールアドレスのログイン名またはローカルパートにすることができます。一般に、uauthzidはグローバルに一意であると想定してはなりません。
Additional authorization identity schemes MAY be defined in future versions of this document.
追加の承認IDスキームは、このドキュメントの将来のバージョンで定義される場合があります。
The following ciphersuites defined in [6] MUST NOT be used for confidentiality protection of passwords or data:
[6]で定義されている次のciphersuitesは、パスワードまたはデータの機密保護に使用してはなりません。
TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA
tls_null_with_null_null tls_rsa_with_null_md5 tls_rsa_with_null_sha
The following ciphersuites defined in [6] can be cracked easily (less than a week of CPU time on a standard CPU in 1997). The client and server SHOULD carefully consider the value of the password or data being protected before using these ciphersuites:
[6]で定義されている次のciphersuitesは、簡単にひび割れする可能性があります（1997年の標準CPUでのCPU時間の1週間未満）。クライアントとサーバーは、これらのciphersuitesを使用する前に保護されているパスワードまたはデータの値を慎重に考慮する必要があります。
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_DEX_DES40_DES40_DES40PATT_DEX_DES40_DES40_DES40_DES40_DES40_DES40_DES40_DES40_DES40 0_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_ANON_EXPORT_WITH_RC4_40_MD5 TLS_ANON_EX_DEX_DEX_DEX_DEX_DEX_DEX_DEX_DEX_DH_EX_DEX_DEX_DEX_DH_EX_DEX_DEXPORTINE
The following ciphersuites are vulnerable to man-in-the-middle attacks, and SHOULD NOT be used to protect passwords or sensitive data, unless the network configuration is such that the danger of a man-in-the-middle attack is tolerable:
次のCiphersuitesは、中間の攻撃に対して脆弱であり、ネットワーク構成が中間攻撃の危険性が許容できるようなものでない限り、パスワードや機密データを保護するために使用しないでください。
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
A client or server that supports TLS MUST support at least TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
TLSをサポートするクライアントまたはサーバーは、少なくともtls_dhe_dss_with_3des_ede_cbc_shaをサポートする必要があります。
For use with SASL [2], a protocol must specify a service name to be used with various SASL mechanisms, such as GSSAPI. For LDAP, the service name is "ldap", which has been registered with the IANA as a GSSAPI service name.
SASL [2]で使用するには、プロトコルはGSSAPIなどのさまざまなSASLメカニズムで使用するサービス名を指定する必要があります。LDAPの場合、サービス名は「LDAP」です。これは、GSSAPIサービス名としてIANAに登録されています。
Security issues are discussed throughout this memo; the (unsurprising) conclusion is that mandatory security is important, and that session encryption is required when snooping is a problem.
このメモ全体でセキュリティの問題について説明します。（驚くことのない）結論は、強制セキュリティが重要であり、スヌーピングが問題である場合にセッション暗号化が必要であるということです。
Servers are encouraged to prevent modifications by anonymous users. Servers may also wish to minimize denial of service attacks by timing out idle connections, and returning the unwillingToPerform result code rather than performing computationally expensive operations requested by unauthorized clients.
サーバーは、匿名のユーザーによる変更を防ぐことをお勧めします。また、サーバーは、アイドル接続のタイミングを出し、許可されていないクライアントが要求する計算上の高価な操作を実行するのではなく、UnwillingToperformの結果コードを返すことにより、サービス拒否攻撃を最小限に抑えたい場合があります。
A connection on which the client has not performed the Start TLS operation or negotiated a suitable SASL mechanism for connection integrity and encryption services is subject to man-in-the-middle attacks to view and modify information in transit.
クライアントがSTART TLS操作を実行していないか、接続の整合性と暗号化サービスに適したSASLメカニズムを交渉した接続は、輸送中の情報を表示および変更するために、中間攻撃の対象となります。
Additional security considerations relating to the EXTERNAL mechanism to negotiate TLS can be found in [2], [5] and [6].
TLSを交渉するための外部メカニズムに関連する追加のセキュリティ上の考慮事項は、[2]、[5]、[6]に記載されています。
This document is a product of the LDAPEXT Working Group of the IETF. The contributions of its members is greatly appreciated.
このドキュメントは、IETFのLDAPextワーキンググループの製品です。メンバーの貢献は大歓迎です。
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[1] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[2] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[4] Leach、P。およびC. Newman、「SASLメカニズムとして消化認証を使用」、RFC 2831、2000年5月。
[5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[5] Hodges、J.、Morgan、R。、およびM. Wahl、「Lightweight Directory Access Protocol（V3）：輸送層のセキュリティの拡張」、RFC 2830、2000年5月。
[6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[6] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[8] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[8] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
Mark Wahl Sun Microsystems, Inc. 8911 Capital of Texas Hwy #4140 Austin TX 78759 USA
Mark Wahl Sun Microsystems、Inc。8911 Capital of Texas Hwy＃4140 Austin TX 78759 USA
EMail: M.Wahl@innosoft.com
Harald Tveit Alvestrand EDB Maxware Pirsenteret N-7462 Trondheim, Norway
Harald Tveit Alvestrand Edb Maxware Pirsenteret N-7462 Trondheim、Norway
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no
Jeff Hodges Oblix, Inc. 18922 Forge Drive Cupertino, CA 95014 USA
Jeff Hodges Oblix、Inc。18922 Forge Drive Cupertino、CA 95014 USA
Phone: +1-408-861-6656
EMail: JHodges@oblix.com
RL "Bob" Morgan Computing and Communications University of Washington Seattle, WA 98105 USA
RL「ボブ」モーガンコンピューティングアンドコミュニケーションワシントン大学シアトル、ワシントン州98105アメリカ
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。