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

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                      Kurt D. Zeilenga
   8 Intended Category: Standard Track                OpenLDAP Foundation
   9 Expires in six months                                1 November 2002
  10
  11
  12
  13                         LDAP "Who am I?" Operation
  14                    <draft-zeilenga-ldap-authzid-08.txt>
  15
  16
  17 Status of this Memo
  18
  19   This document is an Internet-Draft and is in full conformance with all
  20   provisions of Section 10 of RFC2026.
  21
  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>.
  28
  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.''
  36
  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>.
  41
  42   Copyright 2002, The Internet Society.  All Rights Reserved.
  43
  44   Please see the Copyright section near the end of this document for
  45   more information.
  46
  47
  48 Abstract
  49
  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.
  55
  56
  57
  58 Zeilenga                    LDAP "Who am I?"                    [Page 1]
  59 \f
  60 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-08      1 November 2002
  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 [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.
  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   [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
  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 2. The "Who am I?" Operation
 107
 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
 111
 112
 113
 114 Zeilenga                    LDAP "Who am I?"                    [Page 2]
 115 \f
 116 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-08      1 November 2002
 117
 118
 119   request and response messages.
 120
 121       whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
 122
 123
 124 2.1. The whoami Request
 125
 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
 129   (in hex):
 130
 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
 133
 134
 135 2.2. The whoami Response
 136
 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):
 142
 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
 145       4f 52 47
 146
 147
 148 3. Operational Semantics
 149
 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
 154   request.
 155
 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.
 163
 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
 167
 168
 169
 170 Zeilenga                    LDAP "Who am I?"                    [Page 3]
 171 \f
 172 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-08      1 November 2002
 173
 174
 175   operationsError, protocolError, confidentialityRequired,
 176   insufficientAccessRights, busy, unavailable, unwillingToPerform, or
 177   other) and an absent response field.
 178
 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
 184   operation.
 185
 186
 187 4. Extending the "Who am I?" operation with controls
 188
 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
 193   the controls.
 194
 195
 196 4.1. Proxied Authorization Control
 197
 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
 204   operation.
 205
 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.
 209
 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
 216   [PROXYCTL] use.]]
 217
 218
 219 5. Security Considerations
 220
 221   Identities associated with users may be sensitive information.  When
 222   so, security layers [RFC2829][RFC2830] should be established to
 223
 224
 225
 226 Zeilenga                    LDAP "Who am I?"                    [Page 4]
 227 \f
 228 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-08      1 November 2002
 229
 230
 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.
 234
 235   Servers may place access control or other restrictions upon the use of
 236   this operation.
 237
 238   As with any other extended operations, general LDAP security
 239   considerations [RFC3377] apply.
 240
 241
 242 6. IANA Considerations
 243
 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.
 248
 249   Registration of this protocol mechansism is requested [RFC3383].
 250
 251   Subject: Request for LDAP Protocol Mechansism Registration
 252
 253   Object Identifier: 1.3.6.1.4.1.4203.1.11.3
 254
 255   Description: Who am I?
 256
 257   Person & email address to contact for further information:
 258        Kurt Zeilenga <kurt@openldap.org>
 259
 260   Usage: Extended Operation
 261
 262   Specification: RFCxxxx
 263
 264   Author/Change Controller: IESG
 265
 266   Comments: none
 267
 268
 269 7. Acknowledgment
 270
 271   This document borrows from prior work in this area including
 272   "Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
 273   and Mark Wahl.
 274
 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.
 277
 278
 279
 280
 281
 282 Zeilenga                    LDAP "Who am I?"                    [Page 5]
 283 \f
 284 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-08      1 November 2002
 285
 286
 287 8. Author's Address
 288
 289   Kurt D. Zeilenga
 290   OpenLDAP Foundation
 291   <Kurt@OpenLDAP.org>
 292
 293
 294 9. Normative References
 295
 296   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate
 297              Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 298
 299   [RFC2251]  M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
 300              Protocol (v3)", RFC 2251, December 1997.
 301
 302   [RFC2829]  M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
 303              "Authentication Methods for LDAP", RFC 2829, June 2000.
 304
 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.
 308
 309   [RFC3377]  J. Hodges, R. Morgan, "Lightweight Directory Access
 310              Protocol (v3): Technical Specification", RFC 3377,
 311              September 2002.
 312
 313   [PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
 314              weltman-ldapv3-proxy-xx.txt (a work in progress).
 315
 316
 317 10. Informative References
 318
 319   [RFC3383]  K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
 320              RFC 3383), September 2002.
 321
 322   [ASSIGN]   OpenLDAP Foundation, "OpenLDAP OID Delegations",
 323              http://www.openldap.org/foundation/oid-delegate.txt.
 324
 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).
 328
 329   [PRIVATE]  IANA, "Private Enterprise Numbers",
 330              http://www.iana.org/assignments/enterprise-numbers.
 331
 332
 333 Copyright 2002, The Internet Society.  All Rights Reserved.
 334
 335
 336
 337
 338 Zeilenga                    LDAP "Who am I?"                    [Page 6]
 339 \f
 340 INTERNET-DRAFT       draft-zeilenga-ldap-authzid-08      1 November 2002
 341
 342
 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.
 355
 356   The limited permissions granted above are perpetual and will not be
 357   revoked by the Internet Society or its successors or assigns.
 358
 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.
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Zeilenga                    LDAP "Who am I?"                    [Page 7]
 395 \f