RFC 3829 - Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3829
タイトル : RFC 3829 - LightWeight Directory Access Protocol（LDAP）認証IDリクエストと応答コントロール
翻訳編集 : 自動生成

[要約] RFC 3829は、LDAPの認証IDリクエストとレスポンスコントロールに関する仕様です。目的は、クライアントがサーバーに対して認証IDを要求し、サーバーが応答するための機能を提供することです。

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

LightWeight Directory Access Protocol（LDAP）認証IDリクエストと応答コントロール

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（c）The Internet Society（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.

このドキュメントは、Lightweight Directory Access Protocol（LDAP）バインド操作を、確立する認証IDを要求および返却するメカニズムを拡張します。具体的には、このドキュメントでは、バインド操作で使用するための承認IDリクエストと応答コントロールを定義します。

1. Introduction

1. はじめに

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].

このドキュメントでは、承認IDリクエストコントロールと、バインド操作で確立された認可を要求および返却するための認証ID応答制御のサポートを定義します。承認IDリクエストコントロールは、Lightweight Directory Access Protocol（LDAP）プロトコル[LDAPV3]のバージョン3を認証する場合、クライアントがバインドリクエストでクライアントから提出することができます。LDAPサーバーのBIND応答には、認証ID応答コントロールが含まれる場合があります。応答コントロールには、クライアントが想定したIDが含まれています。これは、バインド中にマッピングステップまたはその他の間接がある場合に役立ち、クライアントにLDAP IDが付与されたものを伝えることができます。証明書を使用したクライアント認証は、これが適用される主な状況です。また、いくつかの簡単な認証とセキュリティレイヤー[SASL]認証メカニズムは、クライアントがDNを明示的に提供することを伴わない場合や、クライアントが提供する認証IDとは異なる認証IDをもたらす可能性があります[AUTH]。

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [RFCKeyWords].

このドキュメントで使用されている「必須」、「必要はない」、「そうは思わない」、「そうでなければ」、「そうでなければ」、「必要はない」というキーワードは、[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).

認証IDリクエスト制御と認証IDの応答制御のサポートは、オブジェクト識別子（OID）の存在によって示されます。サーバーのルートDSA固有のエントリ（DSE）の。

3. Authorization Identity Request Control

3. 認証IDリクエスト制御

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を指定する任意のBINDリクエストに含めることができます。マルチステップバインド操作では、クライアントは各バインドリクエストでコントロールを提供する必要があります。

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は存在しません。

4. Authorization Identity Response Control

4. 認証ID応答制御

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のコントロールフィールドの一部として、バインド操作の最初のバインド要求に認証IDリクエストコントロールが含まれる最終的なBIND応答に含めることができます。

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」です。BIND要求が成功し、ID（匿名ではない）をもたらした場合、ControlValueには、要求者に付与された[auth]セクション9で定義されている認証ID（authzid）が含まれます。BIND要求が匿名の関連付けをもたらした場合、ControlValueフィールドはゼロの長さの文字列です。バインド要求が複数のauthzidをもたらした場合、プライマリAuthzidは制御値フィールドに返されます。

The control is only included in a bind response if the resultCode for the bind operation is success.

バインド操作の結果コードが成功した場合、コントロールはバインド応答にのみ含まれます。

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.

サーバーがこのコントロールを使用する前に機密性保護を導入する必要がある場合（セキュリティ上の考慮事項を参照）、サーバーは、機密保持結果コードを返すことにより、適切な機密性保護が適切な整備保護を維持できないと報告しています。

If the client has insufficient access rights to the requested authorization information, the server reports this by returning the insufficientAccessRights result code.

クライアントが要求された承認情報へのアクセス権が不十分な場合、サーバーは、不十分なアクセス権結果コードを返すことによりこれを報告します。

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.

認証プロセスの一部としてクライアントが提示するアイデンティティは、サーバーによって1つ以上の認証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] Bind要求を発行し、外部メカニズムを指定し、認証IDリクエストコントロールを含めます。BIND応答には、証明書がマッピングされたサーバーのディレクトリ情報ツリー（DIT）のDNを示す認証IDの応答制御が含まれる場合があります。

5. Alternative Approach with Extended Operation

5. 拡張操作を伴う代替アプローチ

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を照会するメカニズムを提供します。バインド応答制御とは対照的に、拡張操作を使用すると、BINDが整合性とデータの機密性保護を確立した後、クライアントは認証アイデンティティを学習できます。拡張操作アプローチの欠点は、「私は誰ですか？」の間の調整の問題です。リクエスト、バインドリクエスト、およびその他のリクエスト、および認証IDを学習するには追加の操作が必要であること。マルチスレッドまたは高帯域幅サーバーアプリケーション環境の場合、バインド応答アプローチが望ましい場合があります。

6. Security Considerations

6. セキュリティに関する考慮事項

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.

認証IDリクエストと応答コントロールは、標準の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を渡すことができます。一部の展開では、これらのIDがプライバシー保護を必要とする機密情報が含まれる場合があります。このような展開では、認証IDリクエストコントロールを使用してバインドリクエストを発行する前に、セキュリティレイヤーを確立する必要があります。

7. IANA Considerations

7. IANAの考慮事項

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].

OIDS 2.16.840.1.113730.3.4.16および2.16.840.1.113730.3.4.15は、それぞれ認証IDリクエストと応答コントロールのために予約されています。認証IDリクエストコントロールは、LDAPプロトコルメカニズム[Ianaldap]として登録されています。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.

[LDAPV3] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。

[LDAPPROT] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.

[Ldapprot] Wahl、M.、Howes、T。and S. Kille、「Lightweight Directory Access Protocol（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Wahl、M.、Alvestrand、H.、Hodges、J。およびR. Morgan、「LDAPの認証方法」、RFC 2829、2000年5月。

[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月。

[LDAPATTRS] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.

[ldapattrs] Wahl、M.、Coulbeck、A.、Howes、T。and S. Killee、「Lightweight Directory Access Protocol（V3）：属性構文定義」、RFC 2252、1997年12月。

[IANALDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.

[Ianaldap] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。

8.2. Informative References

8.2. 参考引用

[AUTHZID] Zeilenga, K., "LDAP 'Who am I?' Operation", Work in Progress, April 2002.

[authzid] Zeilenga、K。、「ldap '私は誰ですか？」Operation」、2002年4月、進行中の作業。

9. Author's Addresses

9. 著者のアドレス

Rob Weltman America Online 360 W. Caribbean Drive Sunnyvale, CA 94089 USA

Rob Weltman America Online 360 W. Caribean Drive Sunnyvale、CA 94089 USA

   Phone: +1 650 937-3194
   EMail: robw@worldspot.com

Mark Smith Pearl Crescent, LLC 447 Marlpool Drive Saline, MI 48176 USA

Mark Smith Pearl Crescent、LLC 447 Marlpool Drive Saline、MI 48176 USA

   Phone: +1 734 944-2856
   EMail: mcs@pearlcrescent.com

Mark Wahl PO Box 90626 Austin, TX 78709-0626 USA

マークウォールポックス90626テキサス州オースティン78709-0626 USA

10. Full Copyright Statement

10. 完全な著作権声明

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）The Internet Society（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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。