LDAP Bind Response Extension for Returning DN and Attributes

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

Table of Contents

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

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

4. Examples

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

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

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

• 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.¶

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