git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldap-authzid-xx.txt

   1 INTERNET-DRAFT                                      Kurt D. Zeilenga
   2 Intended Category: Standard Track                OpenLDAP Foundation
   3 Expires in six months                               19 November 2004
   4
   5
   6
   7                         LDAP "Who am I?" Operation
   8                    <draft-zeilenga-ldap-authzid-10.txt>
   9
  10
  11 Status of this Memo
  12
  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>.
  19
  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.
  25
  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.
  29
  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."
  34
  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>.
  39
  40   Copyright (C) The Internet Society (2004).  All Rights Reserved.
  41
  42   Please see the Full Copyright section near the end of this document
  43   for more information.
  44
  45
  46 Abstract
  47
  48   This specification provides a mechanism for Lightweight Directory
  49
  50
  51
  52 Zeilenga                    LDAP "Who am I?"                    [Page 1]
  53 \f
  54 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-10     19 November 2004
  55
  56
  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.
  61
  62
  63 Conventions
  64
  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].
  68
  69
  70 1. Background and Intent of Use
  71
  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.
  77
  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.
  87
  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
  95   operation.
  96
  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.
 104
 105
 106
 107
 108 Zeilenga                    LDAP "Who am I?"                    [Page 2]
 109 \f
 110 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-10     19 November 2004
 111
 112
 113 2. The "Who am I?" Operation
 114
 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.
 119
 120       whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
 121
 122
 123 2.1. The whoami Request
 124
 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
 128   (in hex):
 129
 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
 132
 133
 134 2.2. The whoami Response
 135
 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):
 141
 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
 144       4e 45 54
 145
 146
 147 3. Operational Semantics
 148
 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
 153   request.
 154
 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.
 160
 161
 162
 163
 164 Zeilenga                    LDAP "Who am I?"                    [Page 3]
 165 \f
 166 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-10     19 November 2004
 167
 168
 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.
 176
 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.
 183
 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.
 192
 193
 194 4. Extending the "Who am I?" operation with controls
 195
 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
 200   the controls.
 201
 202
 203 4.1. Proxied Authorization Control
 204
 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
 211   operation.
 212
 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.
 216
 217
 218
 219
 220 Zeilenga                    LDAP "Who am I?"                    [Page 4]
 221 \f
 222 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-10     19 November 2004
 223
 224
 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
 231   [PROXYAUTH] use.]]
 232
 233
 234 5. Security Considerations
 235
 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.
 241
 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.
 245
 246   As with any other extended operations, general LDAP security
 247   considerations [RFC3377] apply.
 248
 249
 250 6. IANA Considerations
 251
 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.
 256
 257   Registration of this protocol mechanism [RFC3383] is requested.
 258
 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
 267   Comments: none
 268
 269
 270 7. Acknowledgment
 271
 272   This document borrows from prior work in this area including
 273
 274
 275
 276 Zeilenga                    LDAP "Who am I?"                    [Page 5]
 277 \f
 278 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-10     19 November 2004
 279
 280
 281   "Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark
 282   Smith and Mark Wahl.
 283
 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.
 286
 287
 288 8. Author's Address
 289
 290   Kurt D. Zeilenga
 291   OpenLDAP Foundation
 292
 293   Email: Kurt@OpenLDAP.org
 294
 295
 296 9. References
 297
 298   [[Note to the RFC Editor: please replace the citation tags used in
 299   referencing Internet-Drafts with tags of the form RFCnnnn where
 300   possible.]]
 301
 302
 303 9.1. Normative References
 304
 305   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 306                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 307
 308   [RFC2251]     Wahl, M., T. Howes and S. Kille, "Lightweight Directory
 309                 Access Protocol (v3)", RFC 2251, December 1997.
 310
 311   [RFC2829]     Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan,
 312                 "Authentication Methods for LDAP", RFC 2829, June 2000.
 313
 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.
 317
 318   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
 319                 Protocol (v3): Technical Specification", RFC 3377,
 320                 September 2002.
 321
 322   [PROXYAUTH]   Weltman, R., "LDAP Proxy Authentication Control",
 323                 draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
 324
 325
 326 9.2. Informative References
 327
 328   [RFC3383]     Zeilenga, K., "IANA Considerations for LDAP", BCP 64
 329
 330
 331
 332 Zeilenga                    LDAP "Who am I?"                    [Page 6]
 333 \f
 334 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-10     19 November 2004
 335
 336
 337                 (also RFC 3383), September 2002.
 338
 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
 342                 progress.
 343
 344   [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
 345                 http://www.openldap.org/foundation/oid-delegate.txt.
 346
 347   [PRIVATE]     IANA, "Private Enterprise Numbers",
 348                 http://www.iana.org/assignments/enterprise-numbers.
 349
 350
 351
 352 Intellectual Property Rights
 353
 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.
 362
 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.
 369
 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
 374   ietf-ipr@ietf.org.
 375
 376
 377
 378 Full Copyright
 379
 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.
 383
 384   This document and the information contained herein are provided on an
 385
 386
 387
 388 Zeilenga                    LDAP "Who am I?"                    [Page 7]
 389 \f
 390 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-10     19 November 2004
 391
 392
 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.
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444 Zeilenga                    LDAP "Who am I?"                    [Page 8]
 445 \f