[要約] RFC 2830は、Lightweight Directory Access Protocol（LDAP）v3のTransport Layer Security（TLS）拡張に関する仕様です。このRFCの目的は、LDAP通信のセキュリティを向上させるために、TLSを使用する方法を定義することです。
Network Working Group J. Hodges
Request for Comments: 2830 Oblix Inc.
Category: Standards Track R. Morgan
Univ of Washington
M. Wahl
Sun Microsystems, Inc.
May 2000
Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
Lightweight Directory Access Protocol（V3）：輸送層のセキュリティの拡張
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of an LDAP extended request.
このドキュメントでは、LDAP [LDAPV3、TLS]の「輸送層セキュリティ（TLS）操作を開始」と定義しています。この操作は、LDAP協会でのTLS確立を提供し、LDAP拡張リクエストの観点から定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [ReqsKeywords].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[reqskeywords]に記載されているように解釈される。
This section describes the Start TLS extended request and extended response themselves: how to form the request, the form of the response, and enumerates the various result codes the client MUST be prepared to handle.
このセクションでは、Start TLS拡張リクエストと拡張応答自体について説明します。リクエストの形成方法、応答の形式、およびクライアントが処理する必要があるさまざまな結果コードを列挙します。
The section following this one then describes how to sequence an overall Start TLS Operation.
これに続くセクションでは、全体的な開始TLS操作をシーケンスする方法について説明します。
A client may perform a Start TLS operation by transmitting an LDAP PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the Start TLS operation:
クライアントは、拡張レクエスト[LDAPV3]を含むLDAP PDUを送信することにより、開始TLS操作を実行することができます。
1.3.6.1.4.1.1466.20037
1.3.6.1.4.1.1466.20037
An LDAP ExtendedRequest is defined as follows:
LDAP ExtendedRequestは次のように定義されます。
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
A Start TLS extended request is formed by setting the requestName field to the OID string given above. The requestValue field is absent. The client MUST NOT send any PDUs on this connection following this request until it receives a Start TLS extended response.
Start TLS拡張リクエストは、requestNameフィールドを上記のOID文字列に設定することにより形成されます。RequestValueフィールドはありません。クライアントは、このリクエストに従って、開始TLS拡張応答を受信するまで、この接続にPDUを送信してはなりません。
When a Start TLS extended request is made, the server MUST return an LDAP PDU containing a Start TLS extended response. An LDAP ExtendedResponse is defined as follows:
Start TLS拡張リクエストが作成されると、サーバーはStart TLS拡張応答を含むLDAP PDUを返す必要があります。LDAP ExtendEdendResponseは次のように定義されます。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
A Start TLS extended response MUST contain a responseName field which MUST be set to the same string as that in the responseName field present in the Start TLS extended request. The response field is absent. The server MUST set the resultCode field to either success or one of the other values outlined in section 2.3.
開始TLS拡張応答には、Start TLS拡張リクエストに存在するResponseLameフィールドの文字列と同じ文字列に設定する必要があるResponseNameフィールドを含める必要があります。応答フィールドはありません。サーバーは、結果コードフィールドを成功またはセクション2.3で概説した他の値のいずれかに設定する必要があります。
If the ExtendedResponse contains a resultCode of success, this indicates that the server is willing and able to negotiate TLS. Refer to section 3, below, for details.
ExtendEdendResponseに成功の結果コードが含まれている場合、これはサーバーがTLSを喜んで交渉することができることを示します。詳細については、以下のセクション3を参照してください。
If the ExtendedResponse contains a resultCode other than success, this indicates that the server is unwilling or unable to negotiate TLS.
ExtendEdendResponseに成功以外の結果コードが含まれている場合、これはサーバーがTLSを交渉したくない、または交渉できないことを示します。
If the Start TLS extended request was not successful, the resultCode will be one of:
Start TLS拡張リクエストが成功しなかった場合、ResultCodeは次の1つになります。
operationsError (operations sequencing incorrect; e.g. TLS already established)
OperationSerror（操作シーケンスが正しくありません。たとえば、すでに確立されています）
protocolError (TLS not supported or incorrect PDU structure)
Protocolerror（TLSはサポートされていないか、PDU構造が正しくありません）
referral (this server doesn't do TLS, try this one)
紹介（このサーバーはTLSを実行しません。これを試してください）
unavailable (e.g. some major problem with TLS, or server is shutting down)
利用できません（たとえば、TLSのいくつかの大きな問題、またはサーバーがシャットダウンしています）
The server MUST return operationsError if the client violates any of the Start TLS extended operation sequencing requirements described in section 3, below.
クライアントが以下のセクション3で説明した開始TLS拡張操作シーケンス要件のいずれかに違反した場合、サーバーはOperationsErrorを返す必要があります。
If the server does not support TLS (whether by design or by current configuration), it MUST set the resultCode to protocolError (see section 4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual referral value in the LDAP Result if it returns a resultCode of referral. The client's current session is unaffected if the server does not support TLS. The client MAY proceed with any LDAP operation, or it MAY close the connection.
サーバーがTLSをサポートしていない場合（設計によるものであろうと現在の構成による）、resultCodeをProtocolerror（[LDAPV3]のセクション4.1.1を参照）または紹介に設定する必要があります。サーバーは、紹介の結果コードを返す場合、LDAPの結果に実際の紹介値を含める必要があります。サーバーがTLSをサポートしていない場合、クライアントの現在のセッションは影響を受けません。クライアントは、任意のLDAP操作を続行するか、接続を閉じることができます。
The server MUST return unavailable if it supports TLS but cannot establish a TLS connection for some reason, e.g. the certificate server not responding, it cannot contact its TLS implementation, or if the server is in process of shutting down. The client MAY retry the StartTLS operation, or it MAY proceed with any other LDAP operation, or it MAY close the connection.
サーバーは、TLSをサポートしているが、何らかの理由でTLS接続を確立できない場合、利用できないと返す必要があります。応答していない証明書サーバーは、TLSの実装に連絡することはできません。また、サーバーがシャットダウンの過程にある場合。クライアントは、startTLS操作を再試行するか、他のLDAP操作を続行するか、接続を閉じることがあります。
This section describes the overall procedures clients and servers MUST follow for TLS establishment. These procedures take into consideration various aspects of the overall security of the LDAP association including discovery of resultant security level and assertion of the client's authorization identity.
このセクションでは、クライアントとサーバーがTLS設立のために従わなければならない全体的な手順について説明します。これらの手順は、結果として生じるセキュリティレベルの発見やクライアントの承認IDのアサーションなど、LDAP協会の全体的なセキュリティのさまざまな側面を考慮しています。
Note that the precise effects, on a client's authorization identity, of establishing TLS on an LDAP association are described in detail in section 5.
クライアントの承認アイデンティティに対する正確な効果は、LDAPアソシエーションでTLSを確立することについて、セクション5で詳しく説明していることに注意してください。
The client MAY send the Start TLS extended request at any time after establishing an LDAP association, except that in the following cases the client MUST NOT send a Start TLS extended request:
クライアントは、LDAP協会を確立した後、いつでもStart TLS拡張リクエストを送信できます。ただし、クライアントはSTART TLS拡張リクエストを送信してはなりません。
- if TLS is currently established on the connection, or - during a multi-stage SASL negotiation, or - if there are any LDAP operations outstanding on the connection.
- 現在、TLSが接続で確立されている場合、または - マルチステージSASLネゴシエーション中、または - 接続に発行されるLDAP操作がある場合。
The result of violating any of these requirements is a resultCode of operationsError, as described above in section 2.3.
これらの要件のいずれかに違反した結果は、セクション2.3で上記のように、OperationsErrorの結果コードです。
The client MAY have already performed a Bind operation when it sends a Start TLS request, or the client might have not yet bound.
クライアントは、Start TLSリクエストを送信したときにバインド操作を既に実行している可能性があります。または、クライアントがまだ拘束されていない場合があります。
If the client did not establish a TLS connection before sending any other requests, and the server requires the client to establish a TLS connection before performing a particular request, the server MUST reject that request with a confidentialityRequired or strongAuthRequired result. The client MAY send a Start TLS extended request, or it MAY choose to close the connection.
クライアントが他のリクエストを送信する前にTLS接続を確立しなかった場合、およびサーバーが特定のリクエストを実行する前にクライアントにTLS接続を確立するよう要求する場合、サーバーは機密条項またはStrongAuthRequered結果でその要求を拒否する必要があります。クライアントは、Start TLS拡張リクエストを送信するか、接続を閉じることを選択する場合があります。
The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable.
サーバーは、TLSを交渉する意思があり、成功の結果を得て、拡張応答を返します。できない場合は、上記の文書化された他の結果を返します。
In the successful case, the client, which has ceased to transfer LDAP requests on the connection, MUST either begin a TLS negotiation or close the connection. The client will send PDUs in the TLS Record Protocol directly over the underlying transport connection to the server to initiate TLS negotiation [TLS].
成功した場合、接続のLDAP要求を転送しなくなったクライアントは、TLS交渉を開始するか、接続を閉じる必要があります。クライアントは、TLSネゴシエーション[TLS]を開始するために、基礎となるトランスポート接続を介してTLSレコードプロトコルのPDUを直接送信します。
Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in [TLS]. Please refer to that document for details.
使用するTLSまたはSSLのバージョンを交渉することは、[TLS]で文書化されているTLSハンドシェイクプロトコルの一部です。詳細については、そのドキュメントを参照してください。
After a TLS connection is established on an LDAP association, both parties MUST individually decide whether or not to continue based on the privacy level achieved. Ascertaining the TLS connection's privacy level is implementation dependent, and accomplished by communicating with one's respective local TLS implementation.
LDAP協会でTLS接続が確立された後、両当事者は、達成されたプライバシーレベルに基づいて継続するかどうかを個別に決定する必要があります。TLS Connectionのプライバシーレベルを確認することは実装に依存し、それぞれのローカルTLS実装と通信することで達成されます。
If the client or server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD gracefully close the TLS connection immediately after the TLS negotiation has completed (see sections 4.1 and 5.2, below).
クライアントまたはサーバーが、認証またはプライバシーのレベルが継続するのに十分ではないと判断した場合、TLS交渉が完了した直後にTLS接続を優雅に閉じる必要があります（以下のセクション4.1および5.2を参照）。
The client MAY attempt to Start TLS again, or MAY send an unbind request, or send any other LDAP request.
クライアントは、TLSを再度開始しようとするか、バインドリクエストを送信したり、他のLDAPリクエストを送信したりする場合があります。
The client MAY, upon receipt of a Start TLS extended response indicating success, assert that a specific authorization identity be utilized in determining the client's authorization status. The client accomplishes this via an LDAP Bind request specifying a SASL mechanism of "EXTERNAL" [SASL]. See section 5.1.2, below.
クライアントは、成功を示す開始TLS拡張応答を受信すると、クライアントの承認ステータスを決定する際に特定の認可IDが利用されると主張する場合があります。クライアントは、「外部」[SASL]のSASLメカニズムを指定するLDAPバインドリクエストを介してこれを達成します。以下のセクション5.1.2を参照してください。
The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
クライアントは、中間の攻撃を防ぐために、サーバーの証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名の理解を確認する必要があります。
Matching is performed according to these rules:
一致は、これらのルールに従って実行されます。
- The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use the server's canonical DNS name or any other derived form of name.
- クライアントは、サーバーの証明書で表現されているように、サーバー名と比較する値としてLDAP接続を開くために使用したサーバーホスト名を使用する必要があります。クライアントは、サーバーの標準的なDNS名またはその他の派生形式の名前を使用してはなりません。
- If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
- タイプDNSNAMEのsumbercaltname拡張が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
- Matching is case-insensitive.
- マッチングは症例感受性です。
- The "*" wildcard character is allowed. If present, it applies only to the left-most name component.
- 「*」ワイルドカード文字が許可されています。存在する場合、それは左端の名前コンポーネントにのみ適用されます。
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name), a match in any one of the set is considered acceptable.
例えば。*.bar.comは、bar.comではなく、a.bar.com、b.bar.comなどに一致します。特定のタイプの複数のIDが証明書に存在する場合（たとえば、複数のDNSName名）、セットのいずれかの一致が許容可能であると見なされます。
If the hostname does not match the dNSName-based identity in the certificate per the above check, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection and indicate that the server's identity is suspect. Automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect.
ホスト名が上記のチェックごとに証明書のDNSNAMEベースのIDと一致しない場合、ユーザー指向のクライアントはユーザーに通知する必要があります（クライアントはユーザーに接続を継続する機会を与えることができます）または接続を終了し、接続を終了します。サーバーのIDが疑わしいことを示します。自動化されたクライアントは、接続を閉じて、サーバーのIDが疑わしいことを示すエラーを返し、記録する必要があります。
Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information.
このセクションで説明されているサーバーのIDチェックを超えて、クライアントは、提供することが観察されるサービスを提供することがサーバーが許可されていることを確認するために、さらにチェックする準備をする必要があります。クライアントは、ローカルポリシー情報を使用する必要がある場合があります。
The client MUST refresh any cached server capabilities information (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS session establishment. This is necessary to protect against active-intermediary attacks which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment.
クライアントは、TLSセッションの確立時に、キャッシュされたサーバー機能情報（たとえば、サーバーのルートDSEから、[LDAPV3]のセクション3.4を参照）を更新する必要があります。これは、TLSの確立前に取得されたサーバー機能情報を変更した可能性のあるアクティブな介入攻撃から保護するために必要です。サーバーは、TLS設立後にさまざまな機能を宣伝する場合があります。
Either the client or server MAY terminate the TLS connection on an LDAP association by sending a TLS closure alert. This will leave the LDAP association intact.
クライアントまたはサーバーのいずれかが、TLSクロージャーアラートを送信することにより、LDAPアソシエーションのTLS接続を終了できます。これにより、LDAP協会はそのままになります。
Before closing a TLS connection, the client MUST either wait for any outstanding LDAP operations to complete, or explicitly abandon them [LDAPv3].
TLS接続を閉じる前に、クライアントは、未解決のLDAP操作が完了するのを待つか、明示的にそれらを放棄する必要があります[LDAPV3]。
After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the receipt of the alert, MAY send and receive LDAP PDUs.
終了の開始者が閉鎖アラートを送信した後、他の当事者からアラートを受け取るまでTLSメッセージを破棄する必要があります。TLSレコードプロトコルPDUSの送信をやめ、アラートの受領後、LDAP PDUを送信して受信することができます。
The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs, and MAY send and receive LDAP PDUs.
相手は、閉鎖アラートを受け取った場合、すぐにTLS閉鎖アラートを送信する必要があります。その後、TLSレコードプロトコルPDUSの送信をやめ、LDAP PDUを送信および受信する場合があります。
Either the client or server MAY abruptly close the entire LDAP association and any TLS connection established on it by dropping the underlying TCP connection. A server MAY beforehand send the client a Notice of Disconnection [LDAPv3] in this case.
クライアントまたはサーバーのいずれかが、基礎となるTCP接続をドロップすることにより、LDAPアソシエーション全体とその上に確立されたTLS接続全体を突然閉じることができます。この場合、サーバーは事前にクライアントに切断の通知[LDAPV3]を送信する場合があります。
This section describes the effects on a client's authorization identity brought about by establishing TLS on an LDAP association. The default effects are described first, and next the facilities for client assertion of authorization identity are discussed including error conditions. Lastly, the effects of closing the TLS connection are described.
このセクションでは、LDAP協会にTLSを確立することにより、クライアントの承認アイデンティティへの影響について説明します。デフォルトの効果について最初に説明し、次に、エラー条件を含めて、承認アイデンティティのクライアントアサーションの施設について議論されます。最後に、TLS接続を閉じることの効果について説明します。
Authorization identities and related concepts are defined in [AuthMeth].
認証のアイデンティティと関連概念は、[authmeth]で定義されています。
Upon establishment of the TLS connection onto the LDAP association, any previously established authentication and authorization identities MUST remain in force, including anonymous state. This holds even in the case where the server requests client authentication via TLS -- e.g. requests the client to supply its certificate during TLS negotiation (see [TLS]).
LDAP協会にTLS接続を確立すると、以前に確立された認証および承認のアイデンティティは、匿名の状態を含む有効性を維持する必要があります。これは、サーバーがTLSを介してクライアント認証を要求する場合でも保持されます。TLS交渉中にクライアントに証明書を提供するよう要求します（[TLS]を参照）。
A client MAY either implicitly request that its LDAP authorization identity be derived from its authenticated TLS credentials or it MAY explicitly provide an authorization identity and assert that it be used in combination with its authenticated TLS credentials. The former is known as an implicit assertion, and the latter as an explicit assertion.
クライアントは、LDAP認証のアイデンティティを認証されたTLS資格情報から派生させることを暗黙的に要求するか、認証アイデンティティを明示的に提供し、認証されたTLS資格情報と組み合わせて使用することを主張する場合があります。前者は暗黙の主張として知られており、後者は明示的な主張として知られています。
An implicit authorization identity assertion is accomplished after TLS establishment by invoking a Bind request of the SASL form using the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include the optional credentials octet string (found within the SaslCredentials sequence in the Bind Request). The server will derive the client's authorization identity from the authentication identity supplied in the client's TLS credentials (typically a public key certificate) according to local policy. The underlying mechanics of how this is accomplished are implementation specific.
TLS確立のアサーションは、TLSの設立後、「外部」メカニズム名[SASL、LDAPV3]を使用してSASLフォームのバインド要求を呼び出して行われます。）。サーバーは、クライアントのTLS資格情報（通常は公開鍵証明書）で提供された認証ID（ローカルポリシーに従ってクライアントの承認ID）を導き出します。これがどのように達成されるかの基礎となるメカニズムは、実装固有です。
An explicit authorization identity assertion is accomplished after TLS establishment by invoking a Bind request of the SASL form using the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the credentials octet string. This string MUST be constructed as documented in section 9 of [AuthMeth].
TLS確立の後に、「外部」メカニズム名[SASL、LDAPV3]を使用してSASLフォームのバインド要求を呼び出すことにより、明示的な認証IDのアサーションが達成されます。この文字列は、[authmeth]のセクション9に文書化されているように構築する必要があります。
For either form of assertion, the server MUST verify that the client's authentication identity as supplied in its TLS credentials is permitted to be mapped to the asserted authorization identity. The server MUST reject the Bind operation with an invalidCredentials resultCode in the Bind response if the client is not so authorized.
いずれかのアサーションの場合、サーバーは、TLS資格情報で提供されているクライアントの認証IDが、主張された承認IDにマッピングされることが許可されていることを確認する必要があります。サーバーは、クライアントがそれほど許可されていない場合、Bind Responseの無効な結果コードでバインド操作を拒否する必要があります。
Additionally, with either form of assertion, if a TLS session has not been established between the client and server prior to making the SASL EXTERNAL Bind request and there is no other external source of authentication credentials (e.g. IP-level security [IPSEC]), or if, during the process of establishing the TLS session, the server did not request the client's authentication credentials, the SASL EXTERNAL bind MUST fail with a result code of inappropriateAuthentication.
さらに、いずれかのアサーションの形で、SASL外部バインド要求を行う前にクライアントとサーバーの間にTLSセッションが確立されていない場合、認証資格情報の他の外部ソース（例：IPレベルセキュリティ[IPSEC]）はありません。または、TLSセッションを確立するプロセス中に、サーバーがクライアントの認証資格情報を要求しなかった場合、SASLの外部バインドは、不適切な認証の結果コードで失敗する必要があります。
After the above Bind operation failures, any client authentication and authorization state of the LDAP association is lost, so the LDAP association is in an anonymous state after the failure. TLS connection state is unaffected, though a server MAY end the TLS connection, via a TLS close_notify message, based on the Bind failure (as it MAY at any time).
上記のバインド操作の失敗の後、LDAP協会のクライアント認証と認証状態は失われるため、LDAP協会は障害後に匿名の状態になります。TLS接続状態は影響を受けませんが、サーバーは、BIND障害に基づいてTLS close_notifyメッセージを介してTLS接続を終了する場合があります（いつでも）。
Closure of the TLS connection MUST cause the LDAP association to move to an anonymous authentication and authorization state regardless of the state established over TLS and regardless of the authentication and authorization state prior to TLS connection establishment.
TLS接続の閉鎖により、LDAP協会は、TLS接続確立の前に、TLSを介して確立された状態に関係なく、認証と認証状態に関係なく、匿名認証および認証状態に移動する必要があります。
The goals of using the TLS protocol with LDAP are to ensure connection confidentiality and integrity, and to optionally provide for authentication. TLS expressly provides these capabilities, as described in [TLS].
TLSプロトコルをLDAPで使用する目標は、接続の機密性と完全性を確保し、オプションで認証を提供することです。TLSは、[TLS]で説明されているように、これらの機能を明示的に提供します。
All security gained via use of the Start TLS operation is gained by the use of TLS itself. The Start TLS operation, on its own, does not provide any additional security.
開始TLS操作の使用によって得られるすべてのセキュリティは、TLS自体の使用によって得られます。開始TLS操作は、それ自体で追加のセキュリティを提供しません。
The use of TLS does not provide or ensure for confidentiality and/or non-repudiation of the data housed by an LDAP-based directory server. Nor does it secure the data from inspection by the server administrators. Once established, TLS only provides for and ensures confidentiality and integrity of the operations and data in transit over the LDAP association, and only if the implementations on the client and server support and negotiate it.
TLSの使用は、LDAPベースのディレクトリサーバーが抱えるデータの機密性および/または非和解を提供または保証しません。また、サーバー管理者による検査からデータを保護しません。TLSは、クライアントとサーバーの実装がそれをサポートおよびネゴシエートする場合にのみ、LDAP協会を介した輸送中の運用とデータの機密性と整合性のみを提供し、保証します。
The level of security provided though the use of TLS depends directly on both the quality of the TLS implementation used and the style of usage of that implementation. Additionally, an active-intermediary attacker can remove the Start TLS extended operation from the supportedExtension attribute of the root DSE. Therefore, both parties SHOULD independently ascertain and consent to the security level achieved once TLS is established and before beginning use of the TLS connection. For example, the security level of the TLS connection might have been negotiated down to plaintext.
TLSの使用は、使用されるTLS実装の品質とその実装の使用スタイルの両方に直接依存します。さらに、アクティブな介入攻撃者は、ルートDSEのsupportedextension属性からStart TLS拡張操作を削除できます。したがって、両当事者は、TLSが確立された後、TLS接続の使用を開始する前に、セキュリティレベルを独立して確認し、同意する必要があります。たとえば、TLS接続のセキュリティレベルは、プレーンテキストに交渉された可能性があります。
Clients SHOULD either warn the user when the security level achieved does not provide confidentiality and/or integrity protection, or be configurable to refuse to proceed without an acceptable level of security.
クライアントは、達成されたセキュリティレベルが機密性や整合性の保護を提供しない場合、ユーザーに警告するか、許容できるレベルのセキュリティなしで進めることを拒否するように設定できます。
Client and server implementors SHOULD take measures to ensure proper protection of credentials and other confidential data where such measures are not otherwise provided by the TLS implementation.
クライアントとサーバーの実装者は、TLS実装によってそのような措置が提供されない場合に、資格情報やその他の機密データを適切に保護するための措置を講じる必要があります。
Server implementors SHOULD allow for server administrators to elect whether and when connection confidentiality and/or integrity is required, as well as elect whether and when client authentication via TLS is required.
サーバーの実装業者は、サーバー管理者が、接続の機密性や整合性が必要かどうか、および/または整合性が必要なときに選択し、TLSを介したクライアント認証が必要かどうかを選択できるようにする必要があります。
The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their contributions to this document.
著者は、この文書への貢献について、ティム・ハウズ、ポール・ホフマン、ジョン・クリスチャン、シリッシュ・ライ、ジョナサン・トロステル、ハラルド・アルベストラン、マーカス・リーチに感謝します。
[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[Authmeth] Wahl、M.、Alvestrand、H.、Hodges、J。およびR. Morgan、「LDAPの認証方法」、RFC 2829、2000年5月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAPV3] Wahl、M.、Kille S.およびT. Howes、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Reqskeywords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen。「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
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 USA
RL「ボブ」モーガンコンピューティングアンドコミュニケーションワシントン大学シアトル、ワシントン州アメリカ
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Mark Wahl Sun Microsystems, Inc. 8911 Capital of Texas Hwy #4140 Austin TX 78759 USA
Mark Wahl Sun Microsystems、Inc。8911 Capital of Texas Hwy＃4140 Austin TX 78759 USA
EMail: M.Wahl@innosoft.com
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
Copyright (C) The Internet Society (2000). All Rights Reserved.
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エディター機能の資金は現在、インターネット協会によって提供されています。