



Network Working Group                                            J. Khan
Internet-Draft                                            DXC Technology
Intended status: Standards Track                        18 December 2025
Expires: 21 June 2026


      LDAP Bind Response Extension for Returning DN and Attributes
                   draft-khan-ldap-bind-return-dn-00

Abstract

   This document proposes an extension to the LDAP Bind operation to
   optionally return the authenticated subject’s Distinguished Name (DN)
   and selected attributes.  The goal is to reduce the number of client-
   server round trips required to obtain user identity information after
   authentication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on 21 June 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.




Khan                      Expires 21 June 2026                  [Page 1]

Internet-Draft  LDAP Bind Response Extension for Returni   December 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.1.  Bind Request Control  . . . . . . . . . . . . . . . . . .   3
     3.2.  Bind Response Augmentation  . . . . . . . . . . . . . . .   3
     3.3.  Control Value and Encoding  . . . . . . . . . . . . . . .   3
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Current Workflow (RFC 4511 behavior)  . . . . . . . . . .   4
     4.2.  Proposed Workflow (with this extension) . . . . . . . . .   4
     4.3.  Attribute Selection Example . . . . . . . . . . . . . . .   4
   5.  Advantages  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Relationship to Existing RFCs . . . . . . . . . . . . . . . .   5
   9.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In current LDAP practice, a client must perform at least two
   operations to authenticate and retrieve the DN of the subject:

   1.  Bind Request: The client authenticates using a DN and
       credentials.

   2.  Search Request: The client issues a search query to retrieve the
       DN and attributes of the authenticated subject.

   This two-step process introduces unnecessary latency and complexity.
   By allowing the Bind response itself to return the DN and optionally
   attributes, the number of calls is reduced, improving efficiency for
   applications that need immediate access to identity information.

2.  Motivation

   Many modern applications, including single sign-on (SSO) systems and
   microservices, require immediate access to user identity attributes
   after authentication.  The current LDAP model requires a follow-up
   search operation, which adds latency and complexity.  This extension
   simplifies client logic and reduces round trips.

3.  Specification






Khan                      Expires 21 June 2026                  [Page 2]

Internet-Draft  LDAP Bind Response Extension for Returni   December 2025


3.1.  Bind Request Control

   This document defines a new optional LDAP control for the Bind
   request:

   *  Control OID: 1.3.6.1.4.1.xxx.yyy.zzz (to be assigned)

   *  Criticality: OPTIONAL

   *  Control Value: An ASN.1-encoded sequence of attribute descriptions
      requested by the client.  If the sequence is empty or absent, the
      server SHALL return only the DN.

3.2.  Bind Response Augmentation

   If the server supports this extension and the Bind operation
   succeeds, the Bind response SHALL include an attached response
   control carrying:

   *  The Distinguished Name (DN) of the authenticated (authorization)
      identity.

   *  The requested attributes, subject to applicable access control and
      privacy policies.

   *  Attributes not permitted by policy SHALL be omitted; the server
      MAY include per-attribute error indicators within the control
      value.

   If the Bind fails, the server SHALL NOT include this response
   control.

3.3.  Control Value and Encoding

   The request and response control values are defined using ASN.1:

   RequestControlValue ::= SEQUENCE OF AttributeDescription
   ResponseControlValue ::= SEQUENCE {
       authzDN      LDAPDN,
       attributes   SEQUENCE OF PartialAttribute OPTIONAL
   }

   Where AttributeDescription, LDAPDN, and PartialAttribute are as
   defined in RFC 4511.  Servers SHOULD preserve attribute ordering
   requested by the client where feasible.

4.  Examples




Khan                      Expires 21 June 2026                  [Page 3]

Internet-Draft  LDAP Bind Response Extension for Returni   December 2025


4.1.  Current Workflow (RFC 4511 behavior)

   Client                          Server
   ------                          ------
   Bind Request  ---------------->
                                   Bind Response (success)
   Search Request ---------------->
                                   Search Response (dn + attributes)

4.2.  Proposed Workflow (with this extension)

   Client                          Server
   ------                          ------
   Bind Request (with control) -->
                                   Bind Response (dn + attributes)

4.3.  Attribute Selection Example

   Request control value: ["givenName", "mail"]

   Bind Response control value:

   authzDN: uid=jdoe,ou=People,dc=example,dc=com
     attributes: givenName: John mail: jdoe@example.com

5.  Advantages

   *  Reduced number of calls: Authentication and identity retrieval in
      a single step.

   *  Lower latency: Fewer round trips between client and server.

   *  Simplified client logic: No need for a follow-up search.

   *  Clearer authorization identity handling: DN returned alongside
      selected attributes.

6.  Security Considerations

   *  Access Control: Servers MUST enforce authorization and access
      control policies prior to returning any attribute in the Bind
      response control.

   *  Sensitive Data: Sensitive attributes (e.g., userPassword, secrets,
      tokens) MUST NOT be returned.

   *  Privacy: Servers SHOULD minimize data returned by default and
      honor least privilege.



Khan                      Expires 21 June 2026                  [Page 4]

Internet-Draft  LDAP Bind Response Extension for Returni   December 2025


   *  Integrity and Confidentiality: Use of StartTLS or LDAPS is
      RECOMMENDED to protect Bind credentials and returned attributes.

   *  Auditing: Servers SHOULD log the use of this control, subject to
      privacy law and organizational policy.

   *  Downgrade/Capability: Clients MUST NOT assume support; they SHOULD
      fall back to a search when the server does not advertise or honor
      the control.

7.  IANA Considerations

   IANA is requested to assign a new LDAP control OID under the
   appropriate IANA registry.  The descriptive name is:

   LDAP Bind Response Extension for Returning DN and Attributes

   The control is suitable for Standards Track registration.

8.  Relationship to Existing RFCs

   This document defines an LDAP control that extends the Bind operation
   specified in RFC 4511 (“Lightweight Directory Access Protocol (LDAP):
   The Protocol”).  RFC 4511 defines the Bind request and response as an
   authentication mechanism, with the Bind response limited to success
   or failure indicators.  It does not provide a mechanism for returning
   the Distinguished Name (DN) or attributes of the authenticated
   subject.

   The closest related work is RFC 3829 (“Lightweight Directory Access
   Protocol (LDAP) Authorization Identity Request and Response
   Controls”), which introduces a control allowing a client to request
   the authorization identity established by the Bind.  RFC 3829 enables
   a client to confirm the identity string (such as a DN or other
   identifier) but does not return arbitrary attributes of the subject
   entry.

   This document differs from RFC 3829 in that it allows the Bind
   response to return not only the DN but also selected attributes of
   the authenticated subject, subject to access control policies.  Thus,
   this proposal complements RFC 3829 by extending the Bind operation to
   cover attribute retrieval, reducing the need for a subsequent search
   operation.








Khan                      Expires 21 June 2026                  [Page 5]

Internet-Draft  LDAP Bind Response Extension for Returni   December 2025


9.  Conclusion

   This document proposes an LDAP Bind extension that returns the DN and
   optionally attributes of the authenticated subject.  By collapsing
   authentication and identity retrieval into a single operation, the
   protocol reduces overhead and improves efficiency for client
   applications.

Appendix A.  Change Log

   draft-khan-ldap-bind-return-dn-00
   - Initial version of the document.
   - Defined Bind request/response extension and ASN.1 control values.
   - Added Motivation and Examples, including ASCII workflow diagrams.
   - Added Security and IANA considerations.
   - Added Relationship to Existing RFCs (RFC 4511 and RFC 3829).
   - Added Change Log appendix.

Author's Address

   J. Khan
   DXC Technology
   Vancouver, BC, Canada




























Khan                      Expires 21 June 2026                  [Page 6]
