1 INTERNET-DRAFT Kurt D. Zeilenga
2 Intended Category: Standard Track OpenLDAP Foundation
3 Expires in six months 19 November 2004
7 LDAP "Who am I?" Operation
8 <draft-zeilenga-ldap-authzid-10.txt>
13 This document is intended to be, after appropriate review and
14 revision, submitted to the RFC Editor as a Standard Track document.
15 Distribution of this memo is unlimited. Technical discussion of this
16 document will take place on the IETF LDAP Extensions mailing list
17 <ldapext@ietf.org>. Please send editorial comments directly to the
18 author <Kurt@OpenLDAP.org>.
20 By submitting this Internet-Draft, I accept the provisions of Section
21 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
22 applicable patent or other IPR claims of which I am aware have been
23 disclosed, or will be disclosed, and any of which I become aware will
24 be disclosed, in accordance with RFC 3668.
26 Internet-Drafts are working documents of the Internet Engineering Task
27 Force (IETF), its areas, and its working groups. Note that other
28 groups may also distribute working documents as Internet-Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference material
33 or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at
36 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
37 Internet-Draft Shadow Directories can be accessed at
38 <http://www.ietf.org/shadow.html>.
40 Copyright (C) The Internet Society (2004). All Rights Reserved.
42 Please see the Full Copyright section near the end of this document
48 This specification provides a mechanism for Lightweight Directory
52 Zeilenga LDAP "Who am I?" [Page 1]
54 INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
57 Access Protocol (LDAP) clients to obtain the authorization identity
58 which the server has associated with the user or application entity.
59 This mechanism is specified as an LDAP extended operation called the
60 LDAP "Who am I?" operation.
65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
67 document are to be interpreted as described in BCP 14 [RFC2119].
70 1. Background and Intent of Use
72 This specification describes a Lightweight Directory Access Protocol
73 (LDAP) [RFC3377] operation which clients can use to obtain the primary
74 authorization identity in its primary form which the server has
75 associated with the user or application entity. The operation is
76 called the "Who am I?" operation.
78 This specification is intended to replace the existing [AUTHRESP]
79 mechanism which uses Bind request and response controls to request and
80 return the authorization identity. Bind controls are not protected by
81 the security layers established by the Bind operation which includes
82 them. While it is possible to establish security layers using Start
83 TLS [RFC2830] prior to the Bind operation, it is often desirable to
84 use security layers established by the Bind operation. An extended
85 operation sent after a Bind operation is protected by the security
86 layers established by the Bind operation.
88 There are other cases where it is desirable to request the
89 authorization identity which the server associated with the client
90 separately from the Bind operation. For example, the "Who am I?"
91 operation can be augmented with a Proxied Authorization Control
92 [PROXYAUTH] to determine the authorization identity which the server
93 associates with the identity asserted in the Proxied Authorization
94 Control. The "Who am I?" operation can also be used prior to the Bind
97 Servers often associate multiple authorization identities with the
98 client and each authorization identity may be represented by multiple
99 authzId [RFC2829] strings. This operation requests and returns the
100 authzId the server considers to be primary. In the specification, the
101 term "the authorization identity" and "the authzId" are generally to
102 be read as "the primary authorization identity" and the "the primary
103 authzId", respectively.
108 Zeilenga LDAP "Who am I?" [Page 2]
110 INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
113 2. The "Who am I?" Operation
115 The "Who am I?" operation is defined as an LDAP Extended Operation
116 [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
117 (OID). This section details the syntax of the operation's whoami
118 request and response messages.
120 whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
123 2.1. The whoami Request
125 The whoami request is an ExtendedRequest with the requestName field
126 containing the whoamiOID OID and an absent requestValue field. For
127 example, a whoami request could be encoded as the sequence of octets
130 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
131 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
134 2.2. The whoami Response
136 The whoami response is an ExtendedResponse where the responseName
137 field is absent and the response field, if present, is empty or an
138 authzId [RFC2829]. For example, a whoami response returning the
139 authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
140 would be encoded as the sequence of octets (in hex):
142 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
143 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
147 3. Operational Semantics
149 The "Who am I?" operation provides a mechanism, a whoami Request, for
150 the client to request that the server returns the authorization
151 identity it currently associates with the client and provides a
152 mechanism, a whoami Response, for the server to respond to that
155 Servers indicate their support for this extended operation by
156 providing whoamiOID object identifier as a value of the
157 'supportedExtension' attribute type in their root DSE. Server SHOULD
158 advertise this extension only when the client is willing and able to
159 perform this operation.
164 Zeilenga LDAP "Who am I?" [Page 3]
166 INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
169 If the server is willing and able to provide the authorization
170 identity it associates with the client, the server SHALL return a
171 whoami Response with a success resultCode. If the server is treating
172 the client as an anonymous entity, the response field is present but
173 empty. Otherwise the server provides the authzId [RFC2829]
174 representing the authorization identity it currently associates with
175 the client in the response field.
177 If the server is unwilling or unable to provide the authorization
178 identity it associates with the client, the server SHALL return a
179 whoami Response with an appropriate non-success resultCode (such as
180 operationsError, protocolError, confidentialityRequired,
181 insufficientAccessRights, busy, unavailable, unwillingToPerform, or
182 other) and an absent response field.
184 As described in [RFC2251] and [RFC2829], an LDAP session has an
185 "anonymous" association until the client has been successfully
186 authenticated using the Bind operation. Clients MUST NOT invoke the
187 "Who Am I?" operation while any Bind operation is in progress,
188 including between two Bind requests made as part of a multi-stage Bind
189 operation. Where a whoami Request is received in violation of this
190 absolute prohibition, the server should return a whoami Response with
191 an operationsError resultCode.
194 4. Extending the "Who am I?" operation with controls
196 Future specifications may extend the "Who am I?" operation using the
197 control mechanism [RFC2251]. When extended by controls, the "Who am
198 I?" operation requests and returns the authorization identity the
199 server associates with the client in a particular context indicated by
203 4.1. Proxied Authorization Control
205 The Proxied Authorization Control [PROXYAUTH] is used by clients to
206 request that the operation it is attached to operates under the
207 authorization of an assumed identity. The client provides the
208 identity to assume in the Proxied Authorization request control. If
209 the client is authorized to assume the requested identity, the server
210 executes the operation as if the requested identity had issued the
213 As servers often map the asserted authzId to another identity
214 [RFC2829], it is desirable to request the server provide the authzId
215 it associates with the assumed identity.
220 Zeilenga LDAP "Who am I?" [Page 4]
222 INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
225 When a Proxied Authorization Control is be attached to the "Who Am I?"
226 operation, the operation requests the return of the authzId the server
227 associates with the identity asserted in the Proxied Authorization
228 Control. The TBD result code is used to indicate that the server does
229 not allow the client to assume the asserted identity. [[Note to RFC
230 Editor: TBD is to be replaced with the name/code assigned by IANA for
234 5. Security Considerations
236 Identities associated with users may be sensitive information. When
237 so, security layers [RFC2829][RFC2830] should be established to
238 protect this information. This mechanism is specifically designed to
239 allow security layers established by a Bind operation to protect the
240 integrity and/or confidentiality of the authorization identity.
242 Servers may place access control or other restrictions upon the use of
243 this operation. As stated in Section 3, the server SHOULD advertise
244 this extension when it is willing and able to perform the operation.
246 As with any other extended operations, general LDAP security
247 considerations [RFC3377] apply.
250 6. IANA Considerations
252 The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who Am
253 I?" extended operation. This OID was assigned [ASSIGN] by OpenLDAP
254 Foundation, under its IANA-assigned private enterprise allocation
255 [PRIVATE], for use in this specification.
257 Registration of this protocol mechanism [RFC3383] is requested.
259 Subject: Request for LDAP Protocol Mechanism Registration
260 Object Identifier: 1.3.6.1.4.1.4203.1.11.3
261 Description: Who am I?
262 Person & email address to contact for further information:
263 Kurt Zeilenga <kurt@openldap.org>
264 Usage: Extended Operation
265 Specification: RFC XXXX
266 Author/Change Controller: IESG
272 This document borrows from prior work in this area including
276 Zeilenga LDAP "Who am I?" [Page 5]
278 INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
281 "Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark
284 The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
285 command. The whoami(1) command displays the effective user id.
293 Email: Kurt@OpenLDAP.org
298 [[Note to the RFC Editor: please replace the citation tags used in
299 referencing Internet-Drafts with tags of the form RFCnnnn where
303 9.1. Normative References
305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
306 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
308 [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
309 Access Protocol (v3)", RFC 2251, December 1997.
311 [RFC2829] Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan,
312 "Authentication Methods for LDAP", RFC 2829, June 2000.
314 [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
315 Directory Access Protocol (v3): Extension for Transport
316 Layer Security", RFC 2830, May 2000.
318 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
319 Protocol (v3): Technical Specification", RFC 3377,
322 [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control",
323 draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
326 9.2. Informative References
328 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
332 Zeilenga LDAP "Who am I?" [Page 6]
334 INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
337 (also RFC 3383), September 2002.
339 [AUTHRESP] Weltman, R., M. Smith and M. Wahl, "LDAP Authorization
340 Identity Response and Request Controls",
341 draft-weltman-ldapv3-auth-response-xx.txt, a work in
344 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
345 http://www.openldap.org/foundation/oid-delegate.txt.
347 [PRIVATE] IANA, "Private Enterprise Numbers",
348 http://www.iana.org/assignments/enterprise-numbers.
352 Intellectual Property Rights
354 The IETF takes no position regarding the validity or scope of any
355 Intellectual Property Rights or other rights that might be claimed to
356 pertain to the implementation or use of the technology described in
357 this document or the extent to which any license under such rights
358 might or might not be available; nor does it represent that it has
359 made any independent effort to identify any such rights. Information
360 on the procedures with respect to rights in RFC documents can be found
361 in BCP 78 and BCP 79.
363 Copies of IPR disclosures made to the IETF Secretariat and any
364 assurances of licenses to be made available, or the result of an
365 attempt made to obtain a general license or permission for the use of
366 such proprietary rights by implementers or users of this specification
367 can be obtained from the IETF on-line IPR repository at
368 http://www.ietf.org/ipr.
370 The IETF invites any interested party to bring to its attention any
371 copyrights, patents or patent applications, or other proprietary
372 rights that may cover technology that may be required to implement
373 this standard. Please address the information to the IETF at
380 Copyright (C) The Internet Society (2004). This document is subject
381 to the rights, licenses and restrictions contained in BCP 78, and
382 except as set forth therein, the authors retain all their rights.
384 This document and the information contained herein are provided on an
388 Zeilenga LDAP "Who am I?" [Page 7]
390 INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
394 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
395 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
396 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
397 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
444 Zeilenga LDAP "Who am I?" [Page 8]