Network Working Group R. Weltman
Request for Comments: 3829 America Online
Category: Informational M. Smith
Pearl Crescent, LLC
M. Wahl
July 2004
Lightweight Directory Access Protocol (LDAP)
Authorization Identity Request and Response Controls
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation.
この文書では、要求し、それが確立認可IDを返すための機構をLDAP（Lightweight Directory Access Protocol）のバインド操作を拡張します。具体的には、この文書では、バインド操作で使用するための認証アイデンティティ要求と応答コントロールを定義します。
This document defines support for the Authorization Identity Request Control and the Authorization Identity Response Control for requesting and returning the authorization established in a bind operation. The Authorization Identity Request Control may be submitted by a client in a bind request if authenticating with version 3 of the Lightweight Directory Access Protocol (LDAP) protocol [LDAPv3]. In the LDAP server's bind response, it may then include an Authorization Identity Response Control. The response control contains the identity assumed by the client. This is useful when there is a mapping step or other indirection during the bind, so that the client can be told what LDAP identity was granted. Client authentication with certificates is the primary situation where this applies. Also, some Simple Authentication and Security Layer [SASL] authentication mechanisms may not involve the client explicitly providing a DN, or may result in an authorization identity which is different from the authentication identity provided by the client [AUTH].
この文書では、バインド操作に設立許可を要求して返すための認証アイデンティティ要求制御や認可のアイデンティティ応答コントロールのサポートを定義します。 LDAP（Lightweight Directory Access Protocol）のプロトコル[のLDAPv3]のバージョン3を使用して認証場合は認証アイデンティティ・リクエスト・コントロールは、バインド要求でクライアントによって提出することができます。 LDAPサーバのバインド応答では、その後、認証アイデンティティ応答コントロールを含むことができます。応答制御は、クライアントによって想定さ身元が含まれています。クライアントが許可されていたものLDAPアイデンティティ伝えることができるように、バインド時のマッピングステップまたは他の間接がある場合に便利です。証明書によるクライアント認証は、これが適用される主な状況です。また、一部簡易認証セキュリティー層[SASL]認証機構は、明示的にDNを提供し、クライアントを伴わないこと、またはクライアント[AUTH]が提供する認証アイデンティティと異なる認証アイデンティティをもたらすことができます。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [RFCKeyWords].
キーワード「MUST」、「MUST NOT」、「SHOULD」は、「べきではない」、および本書で使用される「MAY」は[RFCKeyWords]で説明されるように解釈されるべきです。
2. Publishing support for the Authorization Identity Request Control and the Authorization Identity Response Control
認証アイデンティティ要求制御や認可のアイデンティティ応答コントロール2.出版サポート
Support for the Authorization Identity Request Control and the Authorization Identity Response Control is indicated by the presence of the Object Identifiers (OIDs) 2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15, respectively, in the supportedControl attribute [LDAPATTRS] of a server's root DSA-specific Entry (DSE).
承認アイデンティティ要求制御と認可アイデンティティ応答制御のサポートのsupportedControl属性に、それぞれのオブジェクト識別子（OID）2.16.840.1.113730.3.4.16と2.16.840.1.113730.3.4.15の存在によって示されている[LDAPATTRS]サーバーのルートDSA固有のエントリ（DSE）の。
This control MAY be included in any bind request which specifies protocol version 3, as part of the controls field of the LDAPMessage as defined in [LDAPPROT]. In a multi-step bind operation, the client MUST provide the control with each bind request.
この制御は、[LDAPPROT]で定義されたLDAPMessageの制御フィールドの一部として、プロトコルバージョン3を指定する任意のバインド要求に含まれるかもしれません。多段階バインド操作では、クライアントは、各バインド要求と制御を提供しなければなりません。
The controlType is "2.16.840.1.113730.3.4.16" and the controlValue is absent.
controlTypeは「2.16.840.1.113730.3.4.16」であるとcontrolValueは存在しません。
This control MAY be included in any final bind response where the first bind request of the bind operation included an Authorization Identity Request Control as part of the controls field of the LDAPMessage as defined in [LDAPPROT].
この制御は、[LDAPPROT]で定義されるようにバインド操作の最初のバインド要求たLDAPMessageの制御フィールドの一部として認証アイデンティティ要求制御を含め、任意の最終的なバインド応答に含まれるかもしれません。
The controlType is "2.16.840.1.113730.3.4.15". If the bind request succeeded and resulted in an identity (not anonymous), the controlValue contains the authorization identity (authzId), as defined in [AUTH] section 9, granted to the requestor. If the bind request resulted in an anonymous association, the controlValue field is a string of zero length. If the bind request resulted in more than one authzId, the primary authzId is returned in the controlValue field.
controlTypeは "2.16.840.1.113730.3.4.15" です。バインド要求が成功したとアイデンティティ（匿名ではない）が生じた場合は、controlValueは、要求者に付与され、[AUTH]セクション9で定義されているように、認可ID（authzidは）が含まれています。バインド要求は、匿名組合が生じた場合は、controlValueフィールドは、長さゼロの文字列です。バインド要求が複数のauthzidはが生じた場合は、主authzidははcontrolValueフィールドに返されます。
The control is only included in a bind response if the resultCode for the bind operation is success.
バインド操作のためのresultCodeが成功である場合、コントロールにのみバインド応答に含まれています。
If the server requires confidentiality protections to be in place prior to use of this control (see Security Considerations), the server reports failure to have adequate confidentiality protections in place by returning the confidentialityRequired result code.
サーバはこのコントロールの使用前の場所にあると機密保護を必要とする場合confidentialityRequired結果コードを返すことによって、サーバーのレポートの失敗が所定の位置に十分な機密保護を持っているために、（セキュリティ上の考慮事項を参照してください）。
If the client has insufficient access rights to the requested authorization information, the server reports this by returning the insufficientAccessRights result code.
クライアントが要求された承認情報への十分なアクセス権を持っている場合、insufficientAccessRightsを返すことによって、サーバレポートこれは、コードを引き起こします。
Identities presented by a client as part of the authentication process may be mapped by the server to one or more authorization identities. The bind response control can be used to retrieve the primary authzId.
認証プロセスの一部として、クライアントによって提示されたアイデンティティは、一の以上の許可IDにサーバーによってマッピングすることができます。バインド応答制御は、主authzidはを取得するために使用することができます。
For example, during client authentication with certificates [AUTH], a client may possess more than one certificate and may not be able to determine which one was ultimately selected for authentication to the server. The subject DN field in the selected certificate may not correspond exactly to a DN in the directory, but rather have gone through a mapping process controlled by the server. Upon completing the certificate-based authentication, the client may issue a SASL [SASL] bind request, specifying the EXTERNAL mechanism and including an Authorization Identity Request Control. The bind response MAY include an Authorization Identity Response Control indicating the DN in the server's Directory Information Tree (DIT) which the certificate was mapped to.
例えば、証明書[AUTH]とクライアント認証時、クライアントは複数の証明書を有することが、最終的にサーバへの認証のために選択されたかを判断することができないかもしれません。選択した証明書のサブジェクトDNフィールドは、ディレクトリ内のDNに正確に対応しないことがあり、むしろサーバによって制御されるマッピングプロセスを経ました。証明書ベースの認証が完了すると、クライアントが外部メカニズムを指定すると承認アイデンティティ要求制御を含め、SASL [SASL]バインド要求を発行することができます。バインド応答は、証明書がマップされた、サーバのディレクトリ情報ツリー（DIT）でDNを示す認証アイデンティティ応答コントロールを含むかもしれません。
The LDAP "Who am I?" [AUTHZID] extended operation provides a mechanism to query the authorization identity associated with a bound connection. Using an extended operation, as opposed to a bind response control, allows a client to learn the authorization identity after the bind has established integrity and data confidentiality protections. The disadvantages of the extended operation approach are coordination issues between "Who am I?" requests, bind requests, and other requests, and that an extra operation is required to learn the authorization identity. For multithreaded or high bandwidth server application environments, the bind response approach may be preferable.
LDAP「私は？」 【authzidは】拡張操作は、結合した接続に関連付けられた認可IDを照会するためのメカニズムを提供します。拡張操作を使用して、バインド応答制御とは反対に、バインドは整合性とデータの機密保護を確立した後、クライアントは、認可アイデンティティを学ぶことができます。拡張操作のアプローチの欠点は、間の調整の問題である「私は誰です？」要求、バインド要求、および他の要求、および余分な操作が認可IDを学ぶために必要であること。マルチスレッドまたは高帯域サーバアプリケーション環境のために、バインド応答アプローチが好ましいかもしれません。
The Authorization Identity Request and Response Controls are subject to standard LDAP security considerations. The controls may be passed over a secure as well as over an insecure channel. They are not protected by security layers negotiated by the bind operation.
認証アイデンティティ要求と応答コントロールは、標準のLDAPセキュリティの考慮の対象となっています。コントロールは、安全でないチャネルを介して安全なだけでなく、上を通過することができます。これらは、バインド操作によって交渉のセキュリティ層によって保護されていません。
The response control allows for an additional authorization identity to be passed. In some deployments, these identities may contain confidential information which require privacy protection. In such deployments, a security layer should be established prior to issuing a bind request with an Authorization Identity Request Control.
応答制御が渡される追加の許可のアイデンティティが可能になります。いくつかの展開では、これらのIDは、プライバシー保護を必要とする機密情報が含まれていてもよいです。このような展開では、セキュリティ層は、認証アイデンティティー・リクエスト・コントロールとバインド要求を発行する前に確立すべきです。
The OIDs 2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15 are reserved for the Authorization Identity Request and Response Controls, respectively. The Authorization Identity Request Control has been registered as an LDAP Protocol Mechanism [IANALDAP].
OIDを2.16.840.1.113730.3.4.16と2.16.840.1.113730.3.4.15はそれぞれ、認証アイデンティティ要求と応答を制御するために予約されています。承認アイデンティティ要求コントロールは、[IANALDAP] LDAPプロトコルメカニズムとして登録されています。
[LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[のLDAPv3]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。
[LDAPPROT] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
【LDAPPROT】ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFCKeyWords] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFCKeyWords]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[AUTH] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[AUTH]ワール、M.、Alvestrand、H.、ホッジス、J.とR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年5月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[LDAPATTRS] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
【LDAPATTRS】ワール、M.、Coulbeck、A.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）：属性の構文定義"、RFC 2252、1997年12月。
[IANALDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[IANALDAP]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。
[AUTHZID] Zeilenga, K., "LDAP 'Who am I?' Operation", Work in Progress, April 2002.
[authzidは] Zeilenga、K.、「LDAP '私が？'操作」、進歩、2002年4月に作業。
Rob Weltman America Online 360 W. Caribbean Drive Sunnyvale, CA 94089 USA
ロブWeltman America Onlineの360 W.カリブ海ドライブサニーベール、CA 94089 USA
Phone: +1 650 937-3194 EMail: robw@worldspot.com
電話：+1 650 937-3194 Eメール：robw@worldspot.com
Mark Smith Pearl Crescent, LLC 447 Marlpool Drive Saline, MI 48176 USA
マーク・スミスパールクレセント、LLC 447 Marlpoolドライブ生理食塩水、MI 48176 USA
Phone: +1 734 944-2856 EMail: mcs@pearlcrescent.com
電話：+1 734 944-2856 Eメール：mcs@pearlcrescent.com
Mark Wahl PO Box 90626 Austin, TX 78709-0626 USA
マーク・ウォールバーグ私書箱90626オースティン、TX 78709 0626へ米国
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。