+ document are to be interpreted as described in RFC 2119 [Keyword].
+
+3. Start TLS Operation
+
+ The Start Transport Layer Security (Start TLS) operation defined in
+ section 4.13 of [Protocol] provides the ability to establish [TLS]
+ on an LDAP connection.
+
+3.1. Sequencing of the Start TLS Operation
+
+ This section describes the overall procedures clients and servers
+ must follow for TLS establishment. These procedures take into
+ consideration various aspects of the overall security of the LDAP
+ association including discovery of resultant security level and
+ assertion of the client's authorization identity.
+
+ Note that the precise effects, on a client's authorization identity,
+ of establishing TLS on an LDAP connection are described in detail in
+ section 3.2.
+
+3.1.1. Start TLS Request
+
+ A client may send the Start TLS extended request at any time after
+ establishing an LDAP connection, except:
+
+ - when TLS is currently established on the connection,
+ - when a multi-stage SASL negotiation is in progress on the
+ connection, or
+ - when there are outstanding LDAP operations on the connection.
+
+ The result of violating any of these requirements is a resultCode of
+ operationsError, as described in [Protocol] section 4.13.2.2. Client
+ implementers should note that it is possible to receive a resultCode
+ of success for a Start TLS operation that is sent on a connection
+ with outstanding LDAP operations if the server has sufficient time
+ to process them prior to its receiving the Start TLS request.
+ Implementors of clients should ensure that they do not inadvertently
+ depend upon this race condition.
+
+
+
+Harrison Expires July 2004 [Page 6]
+\f
+Internet-Draft LDAP Authentication Methods 5 December 2003
+
+ There is no requirement that the client have or have not already
+ performed a Bind operation (section 4) before sending a Start TLS
+ operation request.
+
+ If the client did not establish a TLS connection before sending some
+ other request, and the server requires the client to establish a TLS
+ connection before performing that request, the server MUST reject
+ that request by sending a resultCode of confidentialityRequired or
+ strongAuthRequired.
+
+ An LDAP server which requests that clients provide their certificate
+ during TLS negotiation MAY use a local security policy to determine
+ whether to successfully complete TLS negotiation if the client did
+ not present a certificate which could be validated.
+
+3.1.2. Start TLS Response
+
+ 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 resultCode values (documented in [Protocol] section 4.13.2.2)
+ if it is unwilling or unable to do so.
+
+ In the successful case, the client (which has ceased to transfer
+ LDAP requests on the connection) MUST either begin a TLS negotiation
+ or close the connection. The client will send PDUs in the TLS Record
+ Protocol directly over the underlying transport connection to the
+ server to initiate [TLS] negotiation.
+
+3.1.3. TLS Version Negotiation
+
+ Negotiating the version of TLS to be used is a part of the TLS
+ Handshake Protocol [TLS]. Please refer to that document for details.
+
+3.1.4. Discovery of Resultant Security Level
+
+ After a TLS connection is established on an LDAP connection, both
+ parties must individually decide whether or not to continue based on
+ the security level achieved. Ascertaining the TLS connection's
+ security level is implementation dependent and accomplished by
+ communicating with one's respective local TLS implementation.
+
+ If the client or server decides that the level of authentication or
+ security is not high enough for it to continue, it SHOULD gracefully
+ close the TLS connection immediately after the TLS negotiation has
+ completed (see [Protocol] section 4.13.3.1 and section 3.2.3 below).
+ If the client decides to continue, it may gracefully close the TLS
+ connection and attempt to Start TLS again, it may send an unbind
+ request, or it may send any other LDAP request.
+
+3.1.5. 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.
+
+Harrison Expires July 2004 [Page 7]
+\f
+Internet-Draft LDAP Authentication Methods 5 December 2003
+
+
+ Matching is performed according to these rules:
+
+ - The client MUST use the server provided by the user (or other
+ trusted entity) as the value to compare against the server name
+ as expressed in the server's certificate. A hostname derived
+ from the user input is to be considered provided by the user
+ only if derived in a secure fashion (e.g., DNSSEC).
+
+ - 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.
+
+ For example, *.bar.com would match a.bar.com and b.bar.com, but
+ it would not match a.x.bar.com nor would it match bar.com. If
+ more than one identity of a given type is present in the
+ certificate (e.g. more than one dNSName name), a match in any
+ one of the set is considered acceptable.
+
+ If the hostname does not match the dNSName-based identity in the
+ certificate per the above check, user-oriented clients SHOULD either
+ notify the user (clients may give the user the opportunity to
+ continue with the connection in any case) or terminate the
+ connection and indicate that the server's identity is suspect.
+ Automated clients SHOULD close the connection, returning and/or
+ logging an error indicating that the server's identity is suspect.
+
+ Beyond the server identity checks described in this section, clients
+ SHOULD be prepared to do further checking to ensure that the server
+ is authorized to provide the service it is observed to provide. The
+ client may need to make use of local policy information in making
+ this determination.
+
+3.1.6. Refresh of Server Capabilities Information
+
+ Upon TLS session establishment, the client SHOULD discard or refresh
+ all information about the server it obtained prior to the initiation
+ of the TLS negotiation and not obtained through secure mechanisms.
+ This protects against active-intermediary attacks that may have
+ altered any server capabilities information retrieved prior to TLS
+ establishment.
+
+ The server may advertise different capabilities after TLS
+ establishment. In particular, the value of supportedSASLMechanisms
+ may be different after TLS has been negotiated (specifically, the
+ EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
+ after a TLS negotiation has been performed).
+
+3.2. Effects of TLS on a Client's Authorization Identity
+
+Harrison Expires July 2004 [Page 8]
+\f
+Internet-Draft LDAP Authentication Methods 5 December 2003
+
+
+ This section describes the effects on a client's authorization
+ identity brought about by establishing TLS on an LDAP connection.
+ The default effects are described first, and next the facilities for
+ client assertion of authorization identity are discussed including
+ error conditions. Finally, the effects of closing the TLS connection
+ are described.
+
+ Authorization identities and related concepts are described in
+ Appendix C.
+
+3.2.1. TLS Connection Establishment Effects
+
+ The decision to keep or invalidate the established authentication
+ and authorization identities in place after TLS closure is a matter
+ of local server policy.
+
+3.2.2. Client Assertion of Authorization Identity
+
+ After successfully establishing a TLS session, a client may request
+ that its credentials exchanged during the TLS establishment be
+ utilized to authenticate the LDAP association and thus determine the
+ client's authorization status. The client accomplishes this via an
+ LDAP Bind request specifying a SASL mechanism of EXTERNAL [SASL]
+ (section 9). LDAP server implementations SHOULD support this
+ authentication method.
+
+3.2.3. TLS Connection Closure Effects
+
+ The decision to keep or invalidate the established authentication
+ and authorization identities in place after TLS closure is a matter
+ of local server policy.