Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
RFC 2830

Document Type RFC - Proposed Standard (May 2000; No errata)
Obsoleted by RFC 4511, RFC 4513, RFC 4510
Updated by RFC 3377
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2830 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Hodges
Request for Comments: 2830                                    Oblix Inc.
Category: Standards Track                                      R. Morgan
                                                      Univ of Washington
                                                                 M. Wahl
                                                  Sun Microsystems, Inc.
                                                                May 2000

              Lightweight Directory Access Protocol (v3):
                 Extension for Transport Layer Security

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document defines the "Start Transport Layer Security (TLS)
   Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
   establishment in an LDAP association and is defined in terms of an
   LDAP extended request.

1.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [ReqsKeywords].

2.  The Start TLS Request

   This section describes the Start TLS extended request and extended
   response themselves: how to form the request, the form of the
   response, and enumerates the various result codes the client MUST be
   prepared to handle.

   The section following this one then describes how to sequence an
   overall Start TLS Operation.

Hodges, et al.              Standards Track                     [Page 1]
RFC 2830     LDAPv3: Extension for Transport Layer Security     May 2000

2.1.  Requesting TLS Establishment

   A client may perform a Start TLS operation by transmitting an LDAP
   PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the
   Start TLS operation:

     1.3.6.1.4.1.1466.20037

   An LDAP ExtendedRequest is defined as follows:

     ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
             requestName             [0] LDAPOID,
             requestValue            [1] OCTET STRING OPTIONAL }

   A Start TLS extended request is formed by setting the requestName
   field to the OID string given above.  The requestValue field is
   absent.  The client MUST NOT send any PDUs on this connection
   following this request until it receives a Start TLS extended
   response.

   When a Start TLS extended request is made, the server MUST return an
   LDAP PDU containing a Start TLS extended response.  An LDAP
   ExtendedResponse is defined as follows:

     ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
             COMPONENTS OF LDAPResult,
             responseName     [10] LDAPOID OPTIONAL,
             response         [11] OCTET STRING OPTIONAL }

   A Start TLS extended response MUST contain a responseName field which
   MUST be set to the same string as that in the responseName field
   present in the Start TLS extended request. The response field is
   absent. The server MUST set the resultCode field to either success or
   one of the other values outlined in section 2.3.

2.2.  "Success" Response

   If the ExtendedResponse contains a resultCode of success, this
   indicates that the server is willing and able to negotiate TLS. Refer
   to section 3, below, for details.

2.3.  Response other than "success"

   If the ExtendedResponse contains a resultCode other than success,
   this indicates that the server is unwilling or unable to negotiate
   TLS.

Hodges, et al.              Standards Track                     [Page 2]
RFC 2830     LDAPv3: Extension for Transport Layer Security     May 2000

   If the Start TLS extended request was not successful, the resultCode
   will be one of:

   operationsError  (operations sequencing incorrect; e.g. TLS already
                    established)

   protocolError    (TLS not supported or incorrect PDU structure)

   referral         (this server doesn't do TLS, try this one)

   unavailable      (e.g. some major problem with TLS, or server is
                    shutting down)

   The server MUST return operationsError if the client violates any of
   the Start TLS extended operation sequencing requirements described in
   section 3, below.

   If the server does not support TLS (whether by design or by current
   configuration), it MUST set the resultCode to protocolError (see
   section 4.1.1 of [LDAPv3]), or to referral. The server MUST include
   an actual referral value in the LDAP Result if it returns a
   resultCode of referral. The client's current session is unaffected if
Show full document text