INTERNET-DRAFT                                               Rob Weltman 
Intended Category: Informational                              Mark Smith 
                                           Netscape Communications Corp. 
                                                               Mark Wahl 
                                                  Sun Microsystems, Inc. 
                                                              April 2002 
 
    
                LDAP Authorization Identity Bind Control 
               draft-weltman-ldapv3-auth-response-07.txt 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. 
    
   Internet-Drafts are working documents of the Internet Task Force 
   (IETF), its areas, and its working groups.  Note that other groups 
   may also distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   This document defines a way for an LDAP [LDAPv3] server to return the 
   identity assumed by a client on binding using the LDAP Control 
   mechanism . 
    
    
1. Introduction 
    
   This document defines support for the Authentication Request Control 
   and the Authorization Identity Bind Control. The Authentication 
   Request Control may be submitted by a client in a bind request if 
   authenticating with version 3 of the LDAP protocol [LDAPv3]. In the 
   LDAP server's bind response, it may then include an Authorization 
   Identity Bind Control. The response control contains the identity 
   assumed by the client. This is useful when there is a mapping step or 
   other indirection during the bind, so that the client can be told 
   what LDAP identity was granted. Client authentication with 
   certificates is the primary situation where this applies. Also, some 
   SASL authentication mechanisms may not involve the client explicitly 
   providing a DN, or may result in an authorization identity which is 
  
Expires October 2002                                          [Page 1] 

AUTHORIZATION IDENTITY BIND CONTROL                         April 2002 
 
 
   different from the authentication identity provided by the client 
   [AUTH]. 
    
   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and 
   "MAY NOT" used in this document  are  to be interpreted as described 
   in [RFCKeyWords]. 
    
    
2. Publishing support for the Authentication Request Control and the 
   Authorization Identity Bind Control 
    
   Support for the Authentication Request Control and the Authorization 
   Identity Bind Control is indicated by the presence of the OIDs 
   2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15, respectively, 
   in the supportedControl attribute of a server's root DSE. 
    
    
3. Authorization Identity Bind Control 
    
    
   This control MAY be included in any bind request which specifies 
   protocol version 3, as part of the controls field of the LDAPMessage 
   as defined in [LDAPv3]. In a multi-step bind operation, the client 
   MUST provide the control with each bind request. 
    
   The controlType is "2.16.840.1.113730.3.4.16" and the controlValue is 
   absent. 
    
    
4. Authorization Identity Response Control 
    
   This control MAY be included in any final bind response where the 
   first bind request of the bind operation included an Authentication 
   Request Control as part of the controls field of the LDAPMessage as 
   defined in [LDAPv3]. 
    
   The controlType is "2.16.840.1.113730.3.4.15". If the bind request   
   succeeded and resulted in an identity (not anonymous), the 
   controlValue contains the authorization identity (authzId), as 
   defined in [AUTH] section 9, granted to the requestor. If the bind 
   request resulted in anonymous authentication, the controlValue field 
   is a string of zero length. If the bind request resulted in more than 
   one authzId, the primary authzId is returned in the controlValue 
   field. 
    
   The control is only included in a bind response if the resultCode for 
   the bind operation is success. 
    
   If the request control is marked critical and the client is not 
   authorized for it, the server MUST return a resultCode of 
   insufficientAccessRights. If the request control is not marked 
   critical and the client is not authorized for it, the server MUST NOT 
   include a response control with the bind response. 
  
Expires October 2002                                           [Page 2 

AUTHORIZATION IDENTITY BIND CONTROL                         April 2002 
 
 
    
   Identities presented by a client as part of the authentication 
   process may be mapped by the server to one or more authorization 
   identities. The bind response control can be used to retrieve the 
   primary authzId. 
    
   For example, during client authentication with certificates [AUTH], a 
   client may possess more than one certificate and not be able to 
   determine which one was ultimately selected for authentication to the 
   server. The subject DN field in the selected certificate may not 
   correspond exactly to a DN in the directory, but rather have gone 
   through a mapping process controlled by the server. On completing the 
   certificate-based authentication, the client may issue a SASL [SASL] 
   bind request, specifying the EXTERNAL mechanism and including an 
   Authorization Identity Bind Control. The bind response MAY include an 
   Authorization Identity Response Control indicating the DN in the 
   server's DIT which the certificate was mapped to. 
    
    
5. Alternative Approach with Extended Operation 
    
   The LDAP "Who am I?" [AUTHZID] extended operation provides a 
   mechanism to query the authorization identity associated with a bound 
   connection. Using an extended operation as opposed to a bind response 
   control allows a client to learn the authorization identity after the 
   bind has has established integrity and data confidentiality 
   protections. The disadvantages of the extended operation approach are 
   coordination issues between "Who am I?" requests, bind requests, and 
   other requests, and that an extra operation is required to learn the 
   authorization identity. For multithreaded or high bandwidth server 
   application environments, the bind response approach may be 
   preferable. 
    
6. Security Considerations 
    
   The Authorization Identity Response Control is subject to standard 
   LDAP security considerations. The control may be passed over a secure 
   as well as over an insecure channel. It is not protected by security 
   layers negotiated by the bind operation. 
    
   The control allows for an additional authorization identity to be 
   passed. In some deployments, these identities may contain 
   confidential information which require privacy protection. In such 
   deployments, a security layer should be established prior to issuing 
   a bind request with an Authorization Identity Bind Control. 
    
    
7. Copyright 
    
   Copyright (C) The Internet Society (2000). All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
  
Expires October 2002                                           [Page 3 

AUTHORIZATION IDENTITY BIND CONTROL                         April 2002 
 
 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph are 
   included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the  purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
    
8. Bibliography 
    
   [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 
        Protocol (v3)", RFC 2251, December 1997. 
    
   [RFCKeyWords] Bradner, Scott, "Key Words for use in RFCs to Indicate 
        Requirement Levels", draft-bradner-key-words-03.txt, January 
        1997. 
    
   [AUTH] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, 
        "Authentication Methods for LDAP", RFC 2829, May 2000. 
    
   [SASL] J. Myers, "Simple Authentication and Security Layer (SASL", 
        RFC 2222, October 1997. 
    
   [ASN.1] X.680 : ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-
        1:1998, Information Technology - Abstract Syntax Notation One 
        (ASN.1): Specification of Basic Notation 
    
   [AUTHZID] K. Zeilenga, "LDAP 'Who am I?' Operation", draft-zeilenga-
        ldap-authzid-02.txt, March 2002 
    
    
    
9. Author's Addresses 
    
   Rob Weltman 
   Netscape Communications Corp. 
   466 Ellis Street 
   Mountain View, CA 94043 
  
Expires October 2002                                           [Page 4 

AUTHORIZATION IDENTITY BIND CONTROL                         April 2002 
 
 
   USA 
   +1 650 937-3194 
   rweltman@netscape.com 
    
   Mark Smith 
   Netscape Communications Corp. 
   466 Ellis Street 
   Mountain View, CA 94043 
   USA 
   +1 650 937-3477 
   mcs@netscape.com 
    
   Mark Wahl 
   Sun Microsystems, Inc. 
   911 Capital of Texas Hwy, Suite 4140 
   Austin, TX 78759  
   USA 
   +1 512 231 7224 
   Mark.Wahl@sun.com 
    
 
    
10. Revision history 
 

10.1 Changes from draft-weltman-ldapv3-auth-response-06.txt 
    
   General 
    
   Changed Intended Category from Standards Track to Informational. 
    
   Swapped the Abstract and Introduction sections 
    
   Added section "Alternative Approach with Extended Operation" 
    
    

10.2 Changes from draft-weltman-ldapv3-auth-response-05.txt 
    
   General 
    
   Change name of control from "Authentication Response Control" to 
   "Authorization Identity Bind Control". 
    
    
   Authorization Identity Bind Control 
    
   Control must be provided with each bind request in a multi-step bind. 
   Replaced "failure" with "resultCode other than success". 
    
    
   Authorization Identity Response Control 
  
Expires October 2002                                           [Page 5 

AUTHORIZATION IDENTITY BIND CONTROL                         April 2002 
 
 
    
   There may be more than one authzId. 
    
    

10.3 Changes from draft-weltman-ldapv3-auth-response-04.txt 
    
   Authentication Request Control 
    
   Removed clause saying that the control may not be marked critical. 
   Added sentence stating that the server should ignore authentication 
   request controls other than on the first bind request in a multi-step 
   bind operation. 
    
    
   Authorization Identity Bind Control 
    
   Added "(authzId)" to "authorization identity". 
    
    
   Security Considerations 
    
   Added a sentence recommending that a security layer be negotiated 
   before issuing a bind request with the authentication request control 
   in deployments where the authorization identity requires privacy 
   protection. 
    
    

10.4 No Changes from draft-weltman-ldapv3-auth-response-03.txt 
    
   No changes 
    

10.5 Changes from draft-weltman-ldapv3-auth-response-02.txt 
    
   Publishing support 
    
   The controls are published in supportedControl, not 
   supportedExtension. 
    
    
   Authorization Identity Bind Control 
    
   The value of an Authorization Identity Bind Control is an 
   authorization identity, not necessarily a DN. 
    
    
   Security Considerations 
    
   Added a short discussion of the fact that an identity is exposed in 
   the response control. 
  
Expires October 2002                                           [Page 6 

AUTHORIZATION IDENTITY BIND CONTROL                         April 2002 
 
 
    
    
   Miscellaneous 
    
   Eliminated BNF for control contents. 
    
    

10.6 Changes from draft-weltman-ldapv3-auth-response-01.txt 
    
   Authentication Request Control 
    
   An Authorization Identity Bind Control is now only returned if the 
   client requested one by submitting an Authentication Request Control. 
    
    
   Contents of Authorization Identity Bind Control 
    
   Rather than returning both the authentication DN and the 
   authentication mechanism, the control only returns the authentication 
   DN. 
    
    

10.7 Changes from draft-weltman-ldapv3-auth-response-00.txt 
    
   Capitalization of ASN.1 macros 
    
   AuthResponseControl and AuthResponseValue are capitalized. 
    
    
   Clarifications 
    
   Added sentence on behavior for anonymous binds. 
 

















  
Expires October 2002                                           [Page 7