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
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of an LDAP extended request.
この文書では、LDAPのための「スタートトランスポート層セキュリティ（TLS）操作」[LDAPv3の、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
どのように要求、応答の形を形成し、そしてクライアントが処理するために準備しなければなりません、さまざまな結果コードを列挙する：このセクションでは、[スタート] TLS拡張要求と拡張応答に自分自身を説明します。
The section following this one then describes how to sequence an overall Start TLS Operation.
この1次のセクションでは、全体的なスタート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の】スタートTLS操作のためのOIDを指定するのExtendedRequestを含むLDAP PDUを送信することによってスタートTLS操作を行うことができます。
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.
スタートTLS拡張要求は、上記のOID列にrequestNameフィールドを設定することにより形成されています。 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:
スタートTLS拡張要求がなされた場合、サーバーは応答Start TLS拡張を含むLDAP PDUを返さなければなりません。次のようにLDAP ExtendedResponseが定義されています。
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は、応答がスタートTLS拡張要求に存在responseNameフィールドと同じ文字列に設定されなければならないresponseNameフィールドを含まなければなりません拡張しました。応答フィールドは存在しません。サーバーは、成功またはセクション2.3に概説されたその他の値のいずれかのどちらかにresultCodeがフィールドを設定しなければなりません。
If the ExtendedResponse contains a resultCode of success, this indicates that the server is willing and able to negotiate TLS. Refer to section 3, below, for details.
ExtendedResponseが成功のresultCodeが含まれている場合は、これは、サーバが喜んおよびTLSを交渉することが可能であることを示しています。詳細については、下記のセクション3を参照してください。
If the ExtendedResponse contains a resultCode other than success, this indicates that the server is unwilling or unable to negotiate TLS.
ExtendedResponseが成功以外のresultCodeが含まれている場合、これは、サーバーが不本意またはTLSを交渉することができないことを示しています。
If the Start TLS extended request was not successful, the resultCode will be one of:
スタートTLS拡張要求が成功しなかった場合、resultCodeがはのいずれかになります。
operationsError (operations sequencing incorrect; e.g. TLS already established)
operationsError（; TLSは、すでに確立され、例えば、誤った操作をシーケンシング）
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をサポートしていない場合（設計によって、または現在の構成によるかどうか）、それははProtocolErrorへのresultCode（[のLDAPv3]のセクション4.1.1を参照）、または紹介にを設定しなければなりません。それは紹介のにresultCodeを返す場合、サーバーは、LDAP結果における実際の紹介値を含まなければなりません。サーバがTLSをサポートしていない場合は、クライアントの現在のセッションは影響を受けません。クライアントは、任意のLDAP操作に進むことができ、またはそれは接続を終えるかもしれません。
The server MUST return unavailable if it supports TLS but cannot establish a TLS connection for some reason, e.g. the certificate server not responding, it cannot contact its TLS implementation, or if the server is in process of shutting down. The client MAY retry the StartTLS operation, or it MAY proceed with any other LDAP operation, or it MAY close the connection.
それがTLSをサポートしていますが、例えば、何らかの理由でTLS接続を確立できない場合、サーバーは利用できません返さなければなりません応答していない証明書サーバは、それがそのTLS実装を連絡することができない、またはサーバーがシャットダウン中である場合。クライアントがStartTLSを操作を再試行する場合もあれば、他のLDAP操作に進むことができ、またはそれは接続を終えるかもしれません。
This section describes the overall procedures clients and servers MUST follow for TLS establishment. These procedures take into consideration various aspects of the overall security of the LDAP association including discovery of resultant security level and assertion of the client's authorization identity.
このセクションでは、クライアントとサーバーがTLSの確立に従わなければならない全体的な手順を説明します。これらの手順を考慮に生じたセキュリティレベルの発見とクライアントの承認のアイデンティティのアサーションを含むLDAP協会の全体的なセキュリティのさまざまな側面を取ります。
Note that the precise effects, on a client's authorization identity, of establishing TLS on an LDAP association are described in detail in section 5.
LDAP協会でTLSを確立する、クライアントの承認のアイデンティティ上の正確な効果は、第5章に詳細に記載されていることに注意してください。
The client MAY send the Start TLS extended request at any time after establishing an LDAP association, except that in the following cases the client MUST NOT send a Start TLS extended request:
クライアントがスタートTLSを送信することが、次の場合にクライアントがスタートTLS拡張要求を送信してはならないことを除いて、LDAPの関連付けを確立した後、任意の時点での要求を拡張：
- 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のresultCodeがあります。
The client MAY have already performed a Bind operation when it sends a Start TLS request, or the client might have not yet bound.
それがスタート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接続を確立するためにクライアントを必要とする場合、サーバはconfidentialityRequiredまたはstrongAuthRequired結果とその要求を拒絶しなければなりません。クライアントがスタートTLS拡張要求を送信することができる、またはそれは、接続を閉じるように選ぶかもしれません。
The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable.
それは喜んでしてTLSを交渉することができる場合、サーバは成功のresultCodeが持つ拡張応答を返します。それができない場合には、上記文書その他resultCodesを、返します。
In the successful case, the client, which has ceased to transfer LDAP requests on the connection, MUST either begin a TLS negotiation or close the connection. The client will send PDUs in the TLS Record Protocol directly over the underlying transport connection to the server to initiate TLS negotiation [TLS].
成功した場合には、接続上でLDAP要求を転送しなくなったクライアントは、TLSネゴシエーションを開始したり、接続を閉じる必要があります。クライアントは、[TLS] 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]に記載されているように使用するTLSまたはSSLのバージョンを交渉することは、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.
TLS接続はLDAP協会に確立された後、双方の当事者が個別に達成プライバシレベルに基づいて継続するかどうかを決定する必要があります。 TLS接続のプライバシーレベルを確認することは実装依存と、1つのそれぞれのローカル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).
クライアントまたはサーバが認証やプライバシーのレベルは、それが継続するために十分に高くないと判断した場合、それは優雅（以下、セクション4.1および5.2を参照）TLSネゴシエーションが完了した直後にTLS接続を閉じる必要があります。
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.
クライアントMAYは、スタート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.
man-in-the-middle攻撃を防ぐために、サーバーの証明書メッセージに提示されたクライアントは、サーバーの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のsubjectAltName拡張が証明書に存在している場合、それはサーバのアイデンティティの源として使用する必要があります。
- Matching is case-insensitive.
- マッチングは大文字と小文字を区別しません。
- The "*" wildcard character is allowed. If present, it applies only to the left-most name component.
- 「*」ワイルドカード文字を許可されています。存在する場合、それは一番左の名前コンポーネントにのみ適用されます。
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name), a match in any one of the set is considered acceptable.
例えば。 * .bar.com a.bar.com、b.bar.comなどにマッチしなくbar.com。与えられたタイプの複数のアイデンティティ証明書（例えば、複数のdNSName名）に存在する場合、セットのいずれかに一致が許容されると考えられます。
If the hostname does not match the dNSName-based identity in the certificate per the above check, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to 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と一致しない場合、ユーザー指向のクライアントは、ユーザーに通知する（クライアントは、ユーザーが任意の場合の接続を継続する機会を与えるかもしれない）、または接続を終了すべきでどちらかとサーバのアイデンティティが疑わしいであることを示しています。自動化されたクライアントは、返却および/またはサーバのアイデンティティが疑わしいことを示すエラーをログに記録する、接続を閉じる必要があります。
Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information.
このセクションで説明するサーバーの身元確認を越えて、クライアントはさらに、サーバは、提供することが観察されたサービスを提供することを許可されていることを確認するチェックを行うために準備する必要があります。クライアントは、ローカルポリシー情報を利用するために必要があるかもしれません。
The client MUST refresh any cached server capabilities information (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS session establishment. This is necessary to protect against active-intermediary attacks which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment.
クライアントは、（例えば、サーバのルートDSEから、[LDAPv3の]のセクション3.4を参照）、キャッシュされたサーバー機能の情報を更新する必要がありTLSセッション確立時を。これは、TLSの確立に先立って取得任意のサーバー機能情報を変更している場合があり、アクティブ中間攻撃から保護することが必要です。サーバはTLS設立後の異なる機能を通知するかもしれません。
Either the client or server MAY terminate the TLS connection on an LDAP association by sending a TLS closure alert. This will leave the LDAP association intact.
クライアントまたはサーバがTLS閉鎖警戒を送ることによって、LDAP協会のTLS接続を終了することができます。これは、完全なLDAP協会を残すだろう。
Before closing a TLS connection, the client MUST either wait for any outstanding LDAP operations to complete, or explicitly abandon them [LDAPv3].
TLS接続を閉じる前に、クライアントは、いずれかの未処理のLDAP操作が完了するのを待つ、または明示的に[のLDAPv3]それらを放棄しなければなりません。
After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the receipt of the alert, MAY send and receive LDAP PDUs.
近くのイニシエータが閉鎖警戒を送った後は、それが他の当事者からのアラートを受信するまで、それはどんなTLSメッセージを捨てなければなりません。これは、TLSレコードプロトコルのPDUを送信しなくなり、アラートの受信、以下、LDAP PDUを送受信し得ます。
The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs, and MAY send and receive LDAP PDUs.
他の当事者は、それが閉鎖アラートを受信した場合、すぐにTLS閉鎖警戒を伝えなければなりません。これは、その後、TLSレコードプロトコルのPDUを送信しなくなり、およびLDAP PDUを送受信し得ます。
Either the client or server MAY abruptly close the entire LDAP association and any TLS connection established on it by dropping the underlying TCP connection. A server MAY beforehand send the client a Notice of Disconnection [LDAPv3] in this case.
クライアントまたはサーバのどちらかが突然全体のLDAP協会、基礎となるTCP接続をドロップすることによって、その上に確立任意の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資格由来するか、それが明示的に認可IDを提供し、それはその認証された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.
バインド要求にSaslCredentials配列内に見出される任意の資格情報オクテット文字列を含まないものと暗黙的な許可IDアサーションは、「外部」メカニズム名を使用してSASL形式のバインド要求を呼び出すことによって、TLSが確立した後に達成される[SASL、のLDAPv3]（ ）。サーバーは、ローカルポリシーに従って、クライアントのTLS資格で供給される認証アイデンティティ（通常は公開鍵証明書）から、クライアントの認可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].
明示的な許可IDアサーションは、クレデンシャルオクテットストリングを含むものと「外部」メカニズム名[SASL、のLDAPv3]を使用してSASL形式のバインド要求を呼び出すことによって、TLSが確立した後に達成されます。 【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にマッピングすることが許可されていることを確かめなければなりません。クライアントがそのように許可されていない場合、サーバーはバインド応じてinvalidCredentialsのresultCodeとのバインド操作を拒絶しなければなりません。
Additionally, with either form of assertion, if a TLS session has not been established between the client and server prior to making the SASL EXTERNAL Bind request and there is no other external source of authentication credentials (e.g. IP-level security [IPSEC]), or if, during the process of establishing the TLS session, the server did not request the client's authentication credentials, the SASL EXTERNAL bind MUST fail with a result code of inappropriateAuthentication.
また、アサーションの形態のいずれかと、TLSセッションが前にSASL EXTERNALバインド要求を行うには、クライアントとサーバの間で確立されておらず、認証資格（例えばIPレベルのセキュリティ[IPSEC]）の他の外部ソースが存在しない場合、サーバーがクライアントの認証資格情報を要求しなかった場合や、TLSセッションを確立するプロセスの間に、SASL EXTERNALバインドはinappropriateAuthenticationの結果コードで失敗しなければなりません。
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は、close_notifyメッセージを介して、TLS接続を終了してもよいけれども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].
LDAPでTLSプロトコルを使用しての目標は、接続の機密性と完全性を保証するために、認証を提供する、オプションになっています。 [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実装の品質とその実装の使い方のスタイルの両方に直接依存します。また、スタートTLSを削除することができ、アクティブ・仲介攻撃者は、ルートDSEのsupportedExtension属性から操作を拡張しました。そのため、両当事者は、独立して確認し、同意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.
作者はこのドキュメントへの貢献のためにティムハウズ、ポール・ホフマン、ジョン・クリスチャン、Shirishライ、ジョナサンTrostle、ハラルドAlvestrand、およびマーカスリーチに感謝します。
[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[AuthMeth]ワール、M.、Alvestrand、H.、ホッジス、J.とR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年5月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
【のLDAPv3]ワール、M.、Kille S.とT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.及びC.アレン。 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
Jeff Hodges Oblix, Inc. 18922 Forge Drive Cupertino, CA 95014 USA
ジェフ・ホッジスのOblix社18922フォージドライブクパチーノ、CA 95014 USA
Phone: +1-408-861-6656 EMail: JHodges@oblix.com
電話：+ 1-408-861-6656 Eメール：JHodges@oblix.com
RL "Bob" Morgan Computing and Communications University of Washington Seattle, WA USA
RL「ボブ」モルガン・コンピューティングとワシントンシアトル、WA USAの通信大学
Phone: +1-206-221-3307 EMail: rlmorgan@washington.edu
電話：+ 1-206-221-3307 Eメール：rlmorgan@washington.edu
Mark Wahl Sun Microsystems, Inc. 8911 Capital of Texas Hwy #4140 Austin TX 78759 USA
マーク・ワールサン・マイクロシステムズ株式会社8911資本テキサス州のハイウェイ＃4140オースティンTX 78759 USA
EMail: M.Wahl@innosoft.com
メールアドレス：M.Wahl@innosoft.com
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。