1
2
3
4
5
6
7Network Working Group                                         R. Weltman
8Request for Comments: 4370                                  Yahoo!, Inc.
9Category: Standards Track                                  February 2006
10
11
12             Lightweight Directory Access Protocol (LDAP)
13                     Proxied Authorization Control
14
15Status of This Memo
16
17   This document specifies an Internet standards track protocol for the
18   Internet community, and requests discussion and suggestions for
19   improvements.  Please refer to the current edition of the "Internet
20   Official Protocol Standards" (STD 1) for the standardization state
21   and status of this protocol.  Distribution of this memo is unlimited.
22
23Copyright Notice
24
25   Copyright (C) The Internet Society (2006).
26
27Abstract
28
29   This document defines the Lightweight Directory Access Protocol
30   (LDAP) Proxy Authorization Control.  The Proxy Authorization Control
31   allows a client to request that an operation be processed under a
32   provided authorization identity instead of under the current
33   authorization identity associated with the connection.
34
351.  Introduction
36
37   Proxy authorization allows a client to request that an operation be
38   processed under a provided authorization identity instead of under
39   the current authorization identity associated with the connection.
40   This document defines support for proxy authorization using the
41   Control mechanism [RFC2251].  The Lightweight Directory Access
42   Protocol [LDAPV3] supports the use of the Simple Authentication and
43   Security Layer [SASL] for authentication and for supplying an
44   authorization identity distinct from the authentication identity,
45   where the authorization identity applies to the whole LDAP session.
46   The Proxy Authorization Control provides a mechanism for specifying
47   an authorization identity on a per-operation basis, benefiting
48   clients that need to perform operations efficiently on behalf of
49   multiple users.
50
51   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
52   used in this document are to be interpreted as described in
53   [KEYWORDS].
54
55
56
57
58Weltman                     Standards Track                     [Page 1]
59
60RFC 4370           LDAP Proxied Authorization Control      February 2006
61
62
632.  Publishing Support for the Proxy Authorization Control
64
65   Support for the Proxy Authorization Control is indicated by the
66   presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
67   the supportedControl attribute [RFC2252] of a server's root
68   DSA-specific Entry (DSE).
69
703.  Proxy Authorization Control
71
72   A single Proxy Authorization Control may be included in any search,
73   compare, modify, add, delete, or modify Distinguished Name (DN) or
74   extended operation request message.  The exception is any extension
75   that causes a change in authentication, authorization, or data
76   confidentiality [RFC2829], such as Start TLS [LDAPTLS] as part of the
77   controls field of the LDAPMessage, as defined in [RFC2251].
78
79   The controlType of the proxy authorization control is
80   "2.16.840.1.113730.3.4.18".
81
82   The criticality MUST be present and MUST be TRUE.  This requirement
83   protects clients from submitting a request that is executed with an
84   unintended authorization identity.
85
86   Clients MUST include the criticality flag and MUST set it to TRUE.
87   Servers MUST reject any request containing a Proxy Authorization
88   Control without a criticality flag or with the flag set to FALSE with
89   a protocolError error.  These requirements protect clients from
90   submitting a request that is executed with an unintended
91   authorization identity.
92
93   The controlValue SHALL be present and SHALL either contain an authzId
94   [AUTH] representing the authorization identity for the request or be
95   empty if an anonymous association is to be used.
96
97   The mechanism for determining proxy access rights is specific to the
98   server's proxy authorization policy.
99
100   If the requested authorization identity is recognized by the server,
101   and the client is authorized to adopt the requested authorization
102   identity, the request will be executed as if submitted by the proxy
103   authorization identity; otherwise, the result code 123 is returned.
104
1054.  Implementation Considerations
106
107   One possible interaction of proxy authorization and normal access
108   control is illustrated here.  During evaluation of a search request,
109   an entry that would have been returned for the search (if submitted
110   by the proxy authorization identity directly) may not be returned if
111
112
113
114Weltman                     Standards Track                     [Page 2]
115
116RFC 4370           LDAP Proxied Authorization Control      February 2006
117
118
119   the server finds that the requester does not have the right to assume
120   the requested identity for searching the entry, even if the entry is
121   within the scope of a search request under a base DN that does imply
122   such rights.  This means that fewer results, or no results, may be
123   returned than would be if the proxy authorization identity issued the
124   request directly.  An example of such a case may be a system with
125   fine-grained access control, where the proxy right requester has
126   proxy rights at the top of a search tree, but not at or below a point
127   or points within the tree.
128
1295.  Security Considerations
130
131   The Proxy Authorization Control method is subject to general LDAP
132   security considerations [RFC2251] [AUTH] [LDAPTLS].  The control may
133   be passed over a secure channel as well as over an insecure channel.
134
135   The control allows for an additional authorization identity to be
136   passed.  In some deployments, these identities may contain
137   confidential information that requires privacy protection.
138
139   Note that the server is responsible for determining if a proxy
140   authorization request is to be honored. "Anonymous" users SHOULD NOT
141   be allowed to assume the identity of others.
142
1436.  IANA Considerations
144
145   The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
146   Authorization Control.  It has been registered as an LDAP Protocol
147   Mechanism [RFC3383].
148
149   A result code (123) has been assigned by the IANA for the case where
150   the server does not execute a request using the proxy authorization
151   identity.
152
1537.  Acknowledgements
154
155   Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
156   formerly of Sun Microsystems, Inc., Kurt Zeilenga of OpenLDAP
157   Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
158   contributed with reviews of this document.
159
160
161
162
163
164
165
166
167
168
169
170Weltman                     Standards Track                     [Page 3]
171
172RFC 4370           LDAP Proxied Authorization Control      February 2006
173
174
1758.  Normative References
176
177   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
178              Requirement Levels", BCP 14, RFC 2119, March 1997.
179
180   [LDAPV3]   Hodges, J. and R. Morgan, "Lightweight Directory Access
181              Protocol (v3): Technical Specification", RFC 3377,
182              September 2002.
183
184   [SASL]     Myers, J., "Simple Authentication and Security Layer
185              (SASL)", RFC 2222, October 1997.
186
187   [AUTH]     Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
188              "Authentication Methods for LDAP", RFC 2829, May 2000.
189
190   [LDAPTLS]  Hodges, J., Morgan, R., and M. Wahl, "Lightweight
191              Directory Access Protocol (v3): Extension for Transport
192              Layer Security", RFC 2830, May 2000.
193
194   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
195              Access Protocol (v3)", RFC 2251, December 1997.
196
197   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
198              "Lightweight Directory Access Protocol (v3): Attribute
199              Syntax Definitions", RFC 2252, December 1997.
200
201   [RFC2829]  Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
202              "Authentication Methods for LDAP", RFC 2829, May 2000.
203
204   [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
205              Considerations for the Lightweight Directory Access
206              Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
207
208Author's Address
209
210   Rob Weltman
211   Yahoo!, Inc.
212   701 First Avenue
213   Sunnyvale, CA 94089
214   USA
215
216   Phone: +1 408 349-5504
217   EMail: robw@worldspot.com
218
219
220
221
222
223
224
225
226Weltman                     Standards Track                     [Page 4]
227
228RFC 4370           LDAP Proxied Authorization Control      February 2006
229
230
231Full Copyright Statement
232
233   Copyright (C) The Internet Society (2006).
234
235   This document is subject to the rights, licenses and restrictions
236   contained in BCP 78, and except as set forth therein, the authors
237   retain all their rights.
238
239   This document and the information contained herein are provided on an
240   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
241   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
242   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
243   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
244   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
245   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
246
247Intellectual Property
248
249   The IETF takes no position regarding the validity or scope of any
250   Intellectual Property Rights or other rights that might be claimed to
251   pertain to the implementation or use of the technology described in
252   this document or the extent to which any license under such rights
253   might or might not be available; nor does it represent that it has
254   made any independent effort to identify any such rights.  Information
255   on the procedures with respect to rights in RFC documents can be
256   found in BCP 78 and BCP 79.
257
258   Copies of IPR disclosures made to the IETF Secretariat and any
259   assurances of licenses to be made available, or the result of an
260   attempt made to obtain a general license or permission for the use of
261   such proprietary rights by implementers or users of this
262   specification can be obtained from the IETF on-line IPR repository at
263   http://www.ietf.org/ipr.
264
265   The IETF invites any interested party to bring to its attention any
266   copyrights, patents or patent applications, or other proprietary
267   rights that may cover technology that may be required to implement
268   this standard.  Please address the information to the IETF at
269   ietf-ipr@ietf.org.
270
271Acknowledgement
272
273   Funding for the RFC Editor function is provided by the IETF
274   Administrative Support Activity (IASA).
275
276
277
278
279
280
281
282Weltman                     Standards Track                     [Page 5]
283
284