RFC4531 日本語訳
4531 Lightweight Directory Access Protocol (LDAP) Turn Operation. K.Zeilenga. June 2006. (Format: TXT=18986 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Zeilenga Request for Comments: 4531 OpenLDAP Foundation Category: Experimental June 2006
Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4531年のOpenLDAP財団カテゴリ: 実験的な2006年6月
Lightweight Directory Access Protocol (LDAP)
Turn Operation
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)は操作をターンします。
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other.
この仕様は、セッションにおけるその後のプロトコル交換のためにクライアントとサーバの役割を逆にするか(「ターンしてください」)、または各同輩がクライアントとサーバの両方としてもう片方に関して務めるのを可能にするためにライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)拡大手術について説明します。
Table of Contents
目次
1. Background and Intent of Use ....................................2
1.1. Terminology ................................................2
2. Turn Operation ..................................................2
2.1. Turn Request ...............................................3
2.2. Turn Response ..............................................3
3. Authentication ..................................................3
3.1. Use with TLS and Simple Authentication .....................4
3.2. Use with TLS and SASL EXTERNAL .............................4
3.3. Use of Mutual Authentication and SASL EXTERNAL .............4
4. TLS and SASL Security Layers ....................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
6.1. Object Identifier ..........................................6
6.2. LDAP Protocol Mechanism ....................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
1. 使用のバックグラウンドと意図…2 1.1. 用語…2 2. 操作をターンしてください…2 2.1. 要求をターンしてください…3 2.2. 応答をターンしてください…3 3. 認証…3 3.1. TLSと簡易認証と共に使用します。4 3.2. TLSとSASLが外部であることの形で使用します。4 3.3. 互いの認証とSASL外部の使用…4 4. TLSとSASLセキュリティ層…5 5. セキュリティ問題…6 6. IANA問題…6 6.1. オブジェクト識別子…6 6.2. LDAPはメカニズムについて議定書の中で述べます…7 7. 参照…7 7.1. 標準の参照…7 7.2. 有益な参照…8
Zeilenga Experimental [Page 1] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[1ページ]RFC4531LDAPは操作2006年6月にターンします。
1. Background and Intent of Use
1. 使用のバックグラウンドと意図
The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511] is a client-server protocol that typically operates over reliable octet-stream transports, such as the Transport Control Protocol (TCP). Generally, the client initiates the stream by connecting to the server's listener at some well-known address.
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC4510][RFC4511]は信頼できる八重奏ストリーム輸送の上で通常作動するクライアント/サーバプロトコルです、Transport Controlプロトコル(TCP)などのように。 一般に、クライアントは、何らかのよく知られるアドレスでサーバのリスナーに接することによって、ストリームを開始します。
There are cases where it is desirable for the server to initiate the stream. Although it certainly is possible to write a technical specification detailing how to implement server-initiated LDAP sessions, this would require the design of new authentication and other security mechanisms to support server-initiated LDAP sessions.
ケースがサーバがストリームを開始するのが、望ましいところにあります。 サーバで開始しているLDAPセッションを実装する方法を詳しく述べる技術仕様書を書くのが確かに可能ですが、これは、サーバで開始しているLDAPセッションをサポートするために新しい認証と他のセキュリティー対策のデザインを必要とするでしょう。
Instead, this document introduces an operation, the Turn operation, which may be used to reverse the client-server roles of the protocol peers. This allows the initiating protocol peer to become the server (after the reversal).
代わりに、このドキュメントは操作、プロトコル同輩のクライアント/サーバの役割を逆にするのに使用されるかもしれないTurn操作を導入します。 これで、開始しているプロトコル同輩はサーバ(反転の後の)になることができます。
As an additional feature, the Turn operation may be used to allow both peers to act in both roles. This is useful where both peers are directory servers that desire to request, as LDAP clients, that operations be performed by the other. This may be useful in replicated and/or distributed environments.
付加的な機能として、Turn操作は、両方の同輩が両方の役割で行動するのを許容するのに使用されるかもしれません。 これは両方の同輩がLDAPクライアントとして操作がもう片方によって実行されるよう要求することを望んでいるディレクトリサーバであるところで役に立ちます。 これは模写されたそして/または、分散している環境で役に立つかもしれません。
This operation is intended to be used between protocol peers that have established a mutual agreement, by means outside of the protocol, that requires reversal of client-server roles, or allows both peers to act both as client and server.
合意を確立したプロトコル同輩の間でこの操作が使用されることを意図して、手段で、それは、プロトコルの外では、クライアント/サーバの役割の反転を必要とするか、または両方の同輩がクライアントとサーバとして務めるのを許容します。
1.1. Terminology
1.1. 用語
Protocol elements are described using ASN.1 [X.680] with implicit tags. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC4511].
プロトコル要素は、内在しているタグがあるASN.1[X.680]を使用することで説明されます。 「BERによってコード化される」という用語は、要素が[RFC4511]のセクション5.1で詳細な制限でBasic Encoding Rules[X.690]を使用することでコード化されることであることを意味します。
2. Turn Operation
2. 操作をターンしてください。
The Turn operation is defined as an LDAP-Extended Operation [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The function of the Turn Operation is to request that the client-server roles be reversed, or, optionally, to request that both protocol peers be able to act both as client and server in respect to the other.
Turn操作は1.3によって特定されたLDAPによって拡張されたOperation[プロトコル、セクション4.12]と定義されます。.6 .1 .1 .19OID。 Turn Operationの機能はまたは、クライアント/サーバの役割が両方のプロトコル同輩がもう片方に関してクライアントとサーバとして機能できるよう要求するために任意に逆にされるよう要求することです。
Zeilenga Experimental [Page 2] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[2ページ]RFC4531LDAPは操作2006年6月にターンします。
2.1. Turn Request
2.1. 回転要求
The Turn request is an ExtendedRequest where the requestName field contains the 1.3.6.1.1.19 OID and the requestValue field is a BER- encoded turnValue:
Turn要求はrequestName分野が1.3を含むところのExtendedRequestです。.6 .1 .1 .19OIDとrequestValue分野はBERのコード化されたturnValueです:
turnValue ::= SEQUENCE {
mutual BOOLEAN DEFAULT FALSE,
identifier LDAPString
}
turnValue:、:= 系列互いのBOOLEAN DEFAULT FALSE、識別子LDAPString
A TRUE mutual field value indicates a request to allow both peers to act both as client and server. A FALSE mutual field value indicates a request to reserve the client and server roles.
TRUEの互いの分野価値はクライアントとサーバFALSEの互いの分野価値がともにクライアントを予約するという要求とサーバーの役割を示すように両方の同輩が行動するのを許容するという要求を示します。
The value of the identifier field is a locally defined policy identifier (typically associated with a mutual agreement for which this turn is be executed as part of).
識別子分野の値が局所的に定義された方針識別子である、(この回転がそうである合意に通常関連づけられて、部分として実行されてください、)
2.2. Turn Response
2.2. 応答をターンしてください。
A Turn response is an ExtendedResponse where the responseName and responseValue fields are absent. A resultCode of success is returned if and only if the responder is willing and able to turn the session as requested. Otherwise, a different resultCode is returned.
Turn応答はresponseNameとresponseValue分野が欠けているExtendedResponseです。 そして、成功のresultCodeを返す、応答者が望んでいて要求された通りセッションをターンできる場合にだけ。 さもなければ、異なったresultCodeを返します。
3. Authentication
3. 認証
This extension's authentication model assumes separate authentication of the peers in each of their roles. A separate Bind exchange is expected between the peers in their new roles to establish identities in these roles.
この拡大の認証モデルはそれぞれの彼らの役割における、同輩の別々の認証を仮定します。 彼らの新しい役割における同輩の間で別々のBind交換がこれらの役割にアイデンティティを確立すると予想されます。
Upon completion of the Turn, the responding peer in its new client role has an anonymous association at the initiating peer in its new server role. If the turn was mutual, the authentication association of the initiating peer in its pre-existing client role is left intact at the responding peer in its pre-existing server role. If the turn was not mutual, this association is void.
Turnの完成のときに、新しいクライアントの役割における応じている同輩には、新しいサーバーの役割に匿名組合が開始している同輩にあります。 回転が互いであったなら、クライアントの役割を先在させることにおける開始している同輩の認証協会はサーバーの役割を先在させるのにおいて応じている同輩で完全なままにされます。 回転が互いでなかったなら、この協会は空です。
The responding peer may establish its identity in its client role by requesting and successfully completing a Bind operation.
応じている同輩は、Bind操作を要求して、首尾よく完了することによって、クライアントの役割にアイデンティティを確立するかもしれません。
The remainder of this section discusses some authentication scenarios. In the protocol exchange illustrations, A refers to the initiating peer (the original client) and B refers to the responding peer (the original server).
このセクションの残りはいくつかの認証シナリオについて議論します。 プロトコル交換イラストでは、Aは開始している同輩(オリジナルのクライアント)について言及します、そして、Bは応じている同輩(オリジナルのサーバ)について言及します。
Zeilenga Experimental [Page 3] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[3ページ]RFC4531LDAPは操作2006年6月にターンします。
3.1. Use with TLS and Simple Authentication
3.1. TLSとの使用と簡易認証
A->B: StartTLS Request
B->A: StartTLS(success) Response
A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
A->B: Bind(success) Response
1>のB: StartTLSはB>A:を要求します。 StartTLS(成功)の応答の1>のB: ひも(簡単な(cn=B、dc=例、dc=ネット、ビーズ秘密))の要求B>A: (成功)応答の1>のBを縛ってください: 回転、(本当である、"XXYYZ") 要求B>A: (成功)応答B>A:をターンしてください。 (簡単(cn=A、dc=例、dc=ネット、Aの秘密))の要求A>Bを縛ってください: ひも(成功)の応答
In this scenario, TLS (Transport Layer Security) [RFC4346] is started and the initiating peer (the original client) establishes its identity with the responding peer prior to the Turn using the DN/password mechanism of the Simple method of the Bind operation. After the turn, the responding peer, in its new client role, establishes its identity with the initiating peer in its new server role.
このシナリオでは、TLS(輸送Layer Security)[RFC4346]は始動されます、そして、開始している同輩(オリジナルのクライアント)はTurnの前の応じている同輩と共にBind操作のSimpleメソッドのDN/パスワードメカニズムを使用することでアイデンティティを確立します。 回転後に、新しいクライアントの役割では、応じている同輩は開始している同輩と共に新しいサーバーの役割にアイデンティティを確立します。
3.2. Use with TLS and SASL EXTERNAL
3.2. TLSとSASLが外部であることの使用
A->B: StartTLS Request
B->A: StartTLS(success) Response
A->B: Bind(SASL(EXTERNAL)) Request
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(SASL(EXTERNAL)) Request
A->B: Bind(success) Response
1>のB: StartTLSはB>A:を要求します。 StartTLS(成功)の応答の1>のB: ひもの(SASL(外部の))はB>A:を要求します。 (成功)応答の1>のBを縛ってください: 回転、(本当である、"XXYYZ") 要求B>A: (成功)応答B>A:をターンしてください。 ひもの(SASL(外部の))は1>のBを要求します: ひも(成功)の応答
In this scenario, TLS is started (with each peer providing a valid certificate), and the initiating peer (the original client) establishes its identity through the use of the EXTERNAL mechanism of the SASL (Simple Authentication and Security Layer) [RFC4422] method of the Bind operation prior to the Turn. After the turn, the responding peer, in its new client role, establishes its identity with the initiating peer in its new server role.
このシナリオでは、TLSは始動されます、そして、(各同輩が有効な証明書を提供していて)開始している同輩(オリジナルのクライアント)はTurnの前でBind操作のSASL(簡単なAuthenticationとSecurity Layer)[RFC4422]メソッドのEXTERNALメカニズムの使用でアイデンティティを確立します。 回転後に、新しいクライアントの役割では、応じている同輩は開始している同輩と共に新しいサーバーの役割にアイデンティティを確立します。
3.3. Use of Mutual Authentication and SASL EXTERNAL
3.3. 互いの認証とSASL外部の使用
A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual authentication. The initiating peer, in its new server role, may use the identity of the responding peer, established by a prior authentication exchange, as its source for "external" identity in subsequent EXTERNAL exchange.
GSSAPIなどの多くのSASLメカニズム[SASL-K5]が互いの認証をサポートします。 新しいサーバーの役割では、開始している同輩は「外部」のアイデンティティにソースとしてその後のEXTERNAL交換に先の認証交換で設立された応じている同輩のアイデンティティを使用するかもしれません。
A->B: Bind(SASL(GSSAPI)) Request
<intermediate messages>
1>のB: ひもの(SASL(GSSAPI))は<の中間的メッセージ>を要求します。
Zeilenga Experimental [Page 4] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[4ページ]RFC4531LDAPは操作2006年6月にターンします。
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(SASL(EXTERNAL)) Request
A->B: Bind(success) Response
B>A: (成功)応答の1>のBを縛ってください: 回転、(本当である、"XXYYZ") 要求B>A: (成功)応答B>A:をターンしてください。 ひもの(SASL(外部の))は1>のBを要求します: ひも(成功)の応答
In this scenario, a GSSAPI mutual-authentication exchange is completed between the initiating peer (the original client) and the responding server (the original server) prior to the turn. After the turn, the responding peer, in its new client role, requests that the initiating peer utilize an "external" identity to establish its LDAP authorization identity.
このシナリオでは、GSSAPI互いの認証交換は回転前に開始している同輩(オリジナルのクライアント)と応じているサーバ(オリジナルのサーバ)の間で終了しています。 回転(新しいクライアントの役割における応じている同輩)が、開始がじっと見るよう要求した後に、LDAP承認のアイデンティティを証明するのに「外部」のアイデンティティを利用してください。
4. TLS and SASL Security Layers
4. TLSとSASLセキュリティ層
As described in [RFC4511], LDAP supports both Transport Layer Security (TLS) [RFC4346] and Simple Authentication and Security Layer (SASL) [RFC4422] security frameworks. The following table illustrates the relationship between the LDAP message layer, SASL layer, TLS layer, and transport connection within an LDAP session.
[RFC4511]で説明されるように、LDAPは、両方のTransport Layer Security(TLS)が[RFC4346]、Simple Authentication、およびSecurity Layer(SASL)[RFC4422]セキュリティフレームワークであるとサポートします。 以下のテーブルはLDAPセッション以内にLDAPメッセージ層と、SASL層と、TLS層と、輸送接続との関係を例証します。
+----------------------+
| LDAP message layer |
+----------------------+ > LDAP PDUs
+----------------------+ < data
| SASL layer |
+----------------------+ > SASL-protected data
+----------------------+ < data
| TLS layer |
Application +----------------------+ > TLS-protected data
------------+----------------------+ < data
Transport | transport connection |
+----------------------+
+----------------------+ | LDAPメッセージ層| +----------------------+ >LDAP PDUs+----------------------+ <データ| SASL層| +----------------------+ >はデータ+をSASL保護しました。----------------------+ <データ| TLS層| アプリケーション+----------------------+ >はデータをTLS保護しました。------------+----------------------+ <データTransport| 輸送接続| +----------------------+
This extension does not alter this relationship, nor does it remove the general restriction against multiple TLS layers, nor does it remove the general restriction against multiple SASL layers.
この拡大はこの関係を変更しません、そして、複数のTLS層に対して一般的な制限を移します、または、それは複数のSASL層に対して一般的な制限を移しません。
As specified in [RFC4511], the StartTLS operation is used to initiate negotiation of a TLS layer. If a TLS is already installed, the StartTLS operation must fail. Upon establishment of the TLS layer, regardless of which peer issued the request to start TLS, the peer that initiated the LDAP session (the original client) performs the "server identity check", as described in Section 3.1.5 of [RFC4513], treating itself as the "client" and its peer as the "server".
[RFC4511]で指定されるように、StartTLS操作はTLS層の交渉を開始するのに使用されます。 TLSが既にインストールされるなら、StartTLS操作は失敗しなければなりません。 TLS層の設立に、TLSを始動するという要求が出されたどの同輩にかかわらずLDAPセッション(オリジナルのクライアント)を開始した同輩は「サーバ身元確認」を実行するか、.5セクション3.1[RFC4513]で説明されるように、「サーバ」として「クライアント」とその同輩としてそれ自体を扱って。
As specified in [RFC4422], a newly negotiated SASL security layer replaces the installed SASL security layer. Though the client/server
[RFC4422]で指定されるように、新たに交渉されたSASLセキュリティ層はインストールされたSASLセキュリティ層を取り替えます。 クライアント/サーバです。
Zeilenga Experimental [Page 5] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[5ページ]RFC4531LDAPは操作2006年6月にターンします。
roles in LDAP, and hence SASL, may be reversed in subsequent exchanges, only one SASL security layer may be installed at any instance.
LDAP、およびしたがって、SASLにおける役割はその後の交換で逆にされるかもしれなくて、1つのSASLセキュリティ層だけをどんなインスタンスにもインストールしてもよいです。
5. Security Considerations
5. セキュリティ問題
Implementors should be aware that the reversing of client/server roles and/or allowing both peers to act as client and server likely introduces security considerations not foreseen by the authors of this document. In particular, the security implications of the design choices made in the authentication and data security models for this extension (discussed in Sections 3 and 4, respectively) are not fully studied. It is hoped that experimentation with this extension will lead to better understanding of the security implications of these models and other aspects of this extension, and that appropriate considerations will be documented in a future document. The following security considerations are apparent at this time.
作成者はクライアント/サーバーの役割、そして/または、クライアントとサーバとしてありそうに機能するように両方の同輩を許容するのを逆にするのがこのドキュメントの作者によって見通されなかったセキュリティ問題を紹介するのを意識しているべきです。 特に、この拡大(セクション3と4では、それぞれ議論する)のために認証とデータ機密保護モデルでされたデザイン選択のセキュリティ含意は完全に研究されるというわけではありません。 この拡大による実験がこれらのモデルのセキュリティ含意とこの拡大の他の局面の、より良い理解に通じて、適切な問題が将来のドキュメントに記録されることが望まれています。 以下のセキュリティ問題はこのとき、明らかです。
Implementors should take special care to process LDAP, SASL, TLS, and other events in the appropriate roles for the peers. Note that while the Turn reverses the client/server roles with LDAP, and in SASL authentication exchanges, it does not reverse the roles within the TLS layer or the transport connection.
作成者は、同輩のために適切な役割におけるLDAP、SASL、TLS、および他のイベントを処理するために特別に注意を払うべきです。 TurnがLDAP、およびSASL認証交換におけるクライアント/サーバーの役割を覆す間TLS層か輸送接続の中で役割を逆にしないことに注意してください。
The responding server (the original server) should restrict use of this operation to authorized clients. Client knowledge of a valid identifier should not be the sole factor in determining authorization to turn.
応じるサーバ(オリジナルのサーバ)はこの操作の使用を認可されたクライアントに制限するべきです。 有効な識別子に関するクライアント知識は承認がターンすることを決定する唯一の要素であるべきではありません。
Where the peers except to establish TLS, TLS should be started prior to the Turn and any request to authenticate via the Bind operation.
TLS、TLSを設立するのを除いた同輩が始めるべきであるところでは、Bind操作で認証するTurnとどんな要求の前にも始められてください。
LDAP security considerations [RFC4511][RFC4513] generally apply to this extension.
一般に、LDAPセキュリティ問題[RFC4511][RFC4513]はこの拡大に適用されます。
6. IANA Considerations
6. IANA問題
The following values [RFC4520] have been registered by the IANA.
以下の値[RFC4520]はIANAによって示されました。
6.1. Object Identifier
6.1. オブジェクト識別子
The IANA has assigned an LDAP Object Identifier to identify the LDAP Turn Operation, as defined in this document.
IANAは、LDAP Turn Operationを特定するために本書では定義されるようにLDAP Object Identifierを割り当てました。
Zeilenga Experimental [Page 6] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[6ページ]RFC4531LDAPは操作2006年6月にターンします。
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC 4531
Author/Change Controller: Author
Comments:
Identifies the LDAP Turn Operation
Subject: 詳細のために連絡するLDAP Object Identifier Registration PersonとEメールアドレスのために以下を要求してください。 カート Zeilenga <kurt@OpenLDAP.org 、gt;、仕様: RFC4531作者/変化コントローラ: コメントを書いてください: LDAP回転操作を特定します。
6.2. LDAP Protocol Mechanism
6.2. LDAPプロトコルメカニズム
The IANA has registered the LDAP Protocol Mechanism described in this document.
IANAは本書では説明されたLDAPプロトコルMechanismを登録しました。
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.1.19
Description: LDAP Turn Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFC 4531
Author/Change Controller: Author
Comments: none
Subject: LDAPプロトコルメカニズム登録オブジェクト識別子のために以下を要求してください。 1.3.6.1.1.19 記述: 詳細のために連絡するLDAP Turn Operation PersonとEメールアドレス: カート Zeilenga <kurt@openldap.org 、gt;、用法: 拡大手術仕様: RFC4531作者/変化コントローラ: コメントを書いてください: なし
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC4346]Dierks、T.、E.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
June 2006.
エド[RFC4422]メリニコフ、A.、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
Protocol (LDAP): Authentication Methods and Security
Mechanisms", RFC 4513, June 2006.
[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日
Zeilenga Experimental [Page 7] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[7ページ]RFC4531LDAPは操作2006年6月にターンします。
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.680]国際電気通信連合--電気通信標準化セクター、「構文記法1(ASN.1)を抜き取ってください--基本的な記法の仕様」、X.680(2002)(ISO/IEC8824-1も: 2002)。
[X.690] International Telecommunication Union -
Telecommunication Standardization Sector,
"Specification of ASN.1 encoding rules: Basic Encoding
Rules (BER), Canonical Encoding Rules (CER), and
Distinguished Encoding Rules (DER)", X.690(2002) (also
ISO/IEC 8825-1:2002).
[X.690]国際電気通信連合--電気通信Standardization Sector、「ASN.1コード化の仕様は統治します」。 「規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)をコード化する基礎」、X.690(2002)(ISO/IEC8825-1も: 2002)。
7.2. Informative References
7.2. 有益な参照
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for the Lightweight Directory
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC4520、2006年6月。
[SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL
Mechanism", Work in Progress, May 2006.
[SASL-K5] メリニコフ、A.、エド、「ケルベロスV5("GSSAPI")SASLメカニズム」(処理中の作業)は2006にそうするかもしれません。
Author's Address
作者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
カートD.Zeilenga OpenLDAP財団
EMail: Kurt@OpenLDAP.org
メール: Kurt@OpenLDAP.org
Zeilenga Experimental [Page 8] RFC 4531 LDAP Turn Operation June 2006
Zeilengaの実験的な[8ページ]RFC4531LDAPは操作2006年6月にターンします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Zeilenga Experimental [Page 9]
Zeilenga実験的です。[9ページ]
一覧
スポンサーリンク
