7 INTERNET-DRAFT Kurt D. Zeilenga
8 Intended Category: Standard Track OpenLDAP Foundation
9 Expires in six months 1 November 2002
13 LDAP "Who am I?" Operation
14 <draft-zeilenga-ldap-authzid-08.txt>
19 This document is an Internet-Draft and is in full conformance with all
20 provisions of Section 10 of RFC2026.
22 This document is intended to be, after appropriate review and
23 revision, submitted to the RFC Editor as a Standard Track document.
24 Distribution of this memo is unlimited. Technical discussion of this
25 document will take place on the IETF LDAP Extension Working Group
26 mailing list <ldapext@ietf.org>. Please send editorial comments
27 directly to the author <Kurt@OpenLDAP.org>.
29 Internet-Drafts are working documents of the Internet Engineering Task
30 Force (IETF), its areas, and its working groups. Note that other
31 groups may also distribute working documents as Internet-Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as ``work in progress.''
37 The list of current Internet-Drafts can be accessed at
38 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
39 Internet-Draft Shadow Directories can be accessed at
40 <http://www.ietf.org/shadow.html>.
42 Copyright 2002, The Internet Society. All Rights Reserved.
44 Please see the Copyright section near the end of this document for
50 This specification provides a mechanism for Lightweight Directory
51 Access Protocol (LDAP) clients to obtain the authorization identity
52 which the server has associated with the user or application entity.
53 This mechanism is specified as an LDAP extended operation called the
54 LDAP "Who am I?" operation.
58 Zeilenga LDAP "Who am I?" [Page 1]
60 INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
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 [AUTHCTL]
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 they are
82 transferred as part of. While it is possible to establish security
83 layers using Start TLS [RFC2830] prior to the Bind operation, it is
84 often desirable to use security layers established by the Bind
85 operation. An extended operation sent after a Bind operation is
86 protected by the security 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 [PROXYCTL] 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.
106 2. The "Who am I?" Operation
108 The "Who am I?" operation is defined as an LDAP Extended Operation
109 [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
110 (OID). This section details the syntax of the operation's whoami
114 Zeilenga LDAP "Who am I?" [Page 2]
116 INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
119 request and response messages.
121 whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
124 2.1. The whoami Request
126 The whoami request is an ExtendedRequest with the requestName field
127 containing the whoamiOID OID and an absent requestValue field. For
128 example, a whoami request could be encoded as the sequence of octets
131 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
132 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
135 2.2. The whoami Response
137 The whoami response is an ExtendedResponse where the responseName
138 field is absent and the response field, if present, is empty or an
139 authzId [RFC2829]. For example, a whoami response returning the
140 authzId "u:kurt@OPENLDAP.ORG" (in response to the example request)
141 would be encoded as the sequence of octets (in hex):
143 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
144 75 3a 6b 75 72 74 40 4f 50 45 4e 4c 44 41 50 2e
148 3. Operational Semantics
150 The "Who am I?" operation provides a mechanism, a whoami Request, for
151 the client to request that the server returns the authorization
152 identity it currently associates with the client and provides a
153 mechanism, a whoami Response, for the server to respond to that
156 If the server is willing and able to provide the authorization
157 identity it associates with the client, the server SHALL return a
158 whoami Response with a success resultCode. If the server is treating
159 the client as an anonymous entity, the response field is present but
160 empty. Otherwise the server provides the authzId [RFC2829]
161 representing the authorization identity it currently associates with
162 the client in the response field.
164 If the server is unwilling or unable to provide the authorization
165 identity it associates with the client, the server SHALL return a
166 whoami Response with an appropriate non-success resultCode (such as
170 Zeilenga LDAP "Who am I?" [Page 3]
172 INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
175 operationsError, protocolError, confidentialityRequired,
176 insufficientAccessRights, busy, unavailable, unwillingToPerform, or
177 other) and an absent response field.
179 As described in [RFC2251] and [RFC2829], an LDAP session has an
180 "anonymous" association until the client has been successfully
181 authenticated using the Bind operation. Clients MUST NOT invoke the
182 "Who Am I?" operation while any Bind operation is in progress,
183 including between two Bind requests made as part of a multi-stage Bind
187 4. Extending the "Who am I?" operation with controls
189 Future specifications may extend the "Who am I?" operation using the
190 control mechanism [RFC2251]. When extended by controls, the "Who am
191 I?" operation requests and returns the authorization identity the
192 server associates with the client in a particular context indicated by
196 4.1. Proxied Authorization Control
198 The Proxied Authorization Control [PROXYCTL] is used by clients to
199 request that the operation it is attached to operates under the
200 authorization of an assumed identity. The client provides the
201 identity to assume in the Proxied Authorization request control. If
202 the client is authorized to assume the requested identity, the server
203 executes the operation as if the requested identity had issued the
206 As servers often map the asserted authzId to another identity
207 [RFC2829], it is desirable to request the server provide the authzId
208 it associates with the assumed identity.
210 When a Proxied Authorization Control is be attached to the "Who Am I?"
211 operation, the operation requests the return of the authzId the server
212 associates with the identity asserted in the Proxied Authorization
213 Control. The TBD result code is used to indicate that the server does
214 not allow the client to assume the asserted identity. [[Note to RFC
215 Editor: TBD is to be replaced with the name/code assigned by IANA for
219 5. Security Considerations
221 Identities associated with users may be sensitive information. When
222 so, security layers [RFC2829][RFC2830] should be established to
226 Zeilenga LDAP "Who am I?" [Page 4]
228 INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
231 protect this information. This mechanism is specifically designed to
232 allow security layers established by a Bind operation to protect the
233 integrity and/or confidentiality of the authorization identity.
235 Servers may place access control or other restrictions upon the use of
238 As with any other extended operations, general LDAP security
239 considerations [RFC3377] apply.
242 6. IANA Considerations
244 This OID 1.3.6.1.4.1.4203.1.11.3 to identify the LDAP "Who Am I?
245 extended operation. This OID was assigned [ASSIGN] by OpenLDAP
246 Foundation, under its IANA-assigned private enterprise allocation
247 [PRIVATE], for use in this specification.
249 Registration of this protocol mechansism is requested [RFC3383].
251 Subject: Request for LDAP Protocol Mechansism Registration
253 Object Identifier: 1.3.6.1.4.1.4203.1.11.3
255 Description: Who am I?
257 Person & email address to contact for further information:
258 Kurt Zeilenga <kurt@openldap.org>
260 Usage: Extended Operation
262 Specification: RFCxxxx
264 Author/Change Controller: IESG
271 This document borrows from prior work in this area including
272 "Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
275 The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
276 command. The whoami(1) command displays the effective user id.
282 Zeilenga LDAP "Who am I?" [Page 5]
284 INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
294 9. Normative References
296 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
297 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
299 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
300 Protocol (v3)", RFC 2251, December 1997.
302 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
303 "Authentication Methods for LDAP", RFC 2829, June 2000.
305 [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
306 Access Protocol (v3): Extension for Transport Layer
307 Security", RFC 2830, May 2000.
309 [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
310 Protocol (v3): Technical Specification", RFC 3377,
313 [PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
314 weltman-ldapv3-proxy-xx.txt (a work in progress).
317 10. Informative References
319 [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
320 RFC 3383), September 2002.
322 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
323 http://www.openldap.org/foundation/oid-delegate.txt.
325 [AUTHCTL] R. Weltman, M. Smith, M. Wahl, "LDAP Authentication
326 Response Control", draft-weltman-ldapv3-auth-response-
327 xx.txt (a work in progress).
329 [PRIVATE] IANA, "Private Enterprise Numbers",
330 http://www.iana.org/assignments/enterprise-numbers.
333 Copyright 2002, The Internet Society. All Rights Reserved.
338 Zeilenga LDAP "Who am I?" [Page 6]
340 INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
343 This document and translations of it may be copied and furnished to
344 others, and derivative works that comment on or otherwise explain it
345 or assist in its implementation may be prepared, copied, published and
346 distributed, in whole or in part, without restriction of any kind,
347 provided that the above copyright notice and this paragraph are
348 included on all such copies and derivative works. However, this
349 document itself may not be modified in any way, such as by removing
350 the copyright notice or references to the Internet Society or other
351 Internet organizations, except as needed for the purpose of
352 developing Internet standards in which case the procedures for
353 copyrights defined in the Internet Standards process must be followed,
354 or as required to translate it into languages other than English.
356 The limited permissions granted above are perpetual and will not be
357 revoked by the Internet Society or its successors or assigns.
359 This document and the information contained herein is provided on an
360 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
361 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
362 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
363 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
394 Zeilenga LDAP "Who am I?" [Page 7]