LDAPS ( Secure Lightweight Directory Access Protocol )

• Requesting TLS Establishment
  A client may perform a Start TLS operation by transmitting an LDAP PDU containing an ExtendedRequest 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 LDAPOID, requestValue 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.



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



• Response other than "uccess"
  If the ExtendedResponse contains a resultCode other than success, this indicates that the server is unwilling or unable to negotiate TLS.
  
  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)

• Requesting to Start TLS on an LDAP Association
  The client may send the Start TLS extended request at any time after establishing an LDAP association, except that in the following cases the client must not send a Start TLS extended request:
  
  if TLS is currently established on the connection
  during a multi-stage SASL negotiation
  if there are any LDAP operations outstanding on the connection.
  
  The client may have already performed a Bind operation when it sends a Start TLS request, or the client might have not yet bound.
  
  If the client did not establish a TLS connection before sending any other requests, and the server requires the client to establish a TLS connection before performing a particular request, the server must reject that request with a confidentialityRequired or strongAuthRequired result. The client may send a Start TLS extended request, or it may choose to close the connection.



• Starting TLS
  The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable.



• TLS Version Negotiation
  Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in. Please refer to that document for details.



• Discovery of Resultant Security Level
  After a TLS connection is established on an LDAP association, both parties must individually decide whether or not to continue based on the privacy level achieved. Ascertaining the TLS connection¡¯s privacy level is implementation dependent, and accomplished by communicating with one¡¯s respective local TLS implementation.



• Assertion of Client's Authorization Identity
  The client may, upon receipt of a Start TLS extended response indicating success, assert that a specific authorization identity be utilized in determining the client's authorization status. The client accomplishes this via an LDAP Bind request specifying a SASL mechanism of EXTERNAL.



• Server Identity Check
  The client must check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.


Matching is performed according to these rules:

The client must use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client must not use the server's canonical DNS name or any other derived form of name.

If a subjectAltName extension of type dNSName is present in the certificate, it should be used as the source of the server¡¯s identity.

Matching is case-insensitive.

The "*" wildcard character is allowed. If present, it applies only to the left-most name component.



• Refresh of Server Capabilities Information
  The client must refresh any cached server capabilities information (e.g. from the server's root DSE) upon TLS session establishment. This is necessary to protect against active-intermediary attacks which may have altered any server capabilities information retrieved prior to TLS establishment. The server may advertise different capabilities after TLS establishment.

• Graceful Closure
  Either the client or server may terminate the TLS connection on an LDAP association by sending a TLS closure alert. This will leave the LDAP association intact.
  
  Before closing a TLS connection, the client must either wait for any outstanding LDAP operations to complete, or explicitly abandon them.
  
  After the initiator of a close has sent a closure alert, it must discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the receipt of the alert, may send and receive LDAP PDUs.
  
  The other party, if it receives a closure alert, must immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs, and may send and receive LDAP PDUs.



• Abrupt Closure
  Either the client or server may abruptly close the entire LDAP association and any TLS connection established on it by dropping the underlying TCP connection. A server may beforehand send the client a Notice of Disconnection in this case.

• TLS Connection Establishment Effects


• Default Effects
  Upon establishment of the TLS connection onto the LDAP association, any previously established authentication and authorization identities must remain in force, including anonymous state. This holds even in the case where the server requests client authentication via TLS -- e.g. requests the client to supply its certificate during TLS negotiation.



• Client Assertion of Authorization Identity
  A client may either implicitly request that its LDAP authorization identity be derived from its authenticated TLS credentials or it may explicitly provide an authorization identity and assert that it be used in combination with its authenticated TLS credentials. The former is known as an implicit assertion, and the latter as an explicit assertion.



• TLS Connection Closure Effects
  Closure of the TLS connection must cause the LDAP association to move to an anonymous authentication and authorization state regardless of the state established over TLS and regardless of the authentication and authorization state prior to TLS connection establishment.

■ Parent layer
■ Child layer

TCP

LDAPS