ietf-corpus

rfc-2830

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

J. Hodges, R. Morgan, M. Wahl
date2000-05 streamIETF areaapp wgldapext statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc2830 doi10.17487/RFC2830
This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS-TRACK]

obsoleted by

updated by

Extracted elements (29)

design-rationale §3.6

The client must use the original connection hostname (not canonical DNS) for server identity verification to prevent a class of MITM attack where DNS canonicalization could redirect to a different server with a legitimately matching certificate.

tls, ldap, security, pkix

design-rationale §6

The Start TLS operation itself provides no additional security on its own; all security is derived from TLS. This is why implementors must not conflate the success of the Start TLS exchange with the security level of the resulting TLS connection.

tls, ldap, security

interoperability-note §3.3

TLS version negotiation (TLS vs. SSL version selection) is handled entirely by the TLS Handshake Protocol as documented in RFC 2246 and is not addressed by the Start TLS LDAP operation.

tls, ldap

normative-requirement §5.1.2.3 MUST

A SASL EXTERNAL Bind MUST fail with inappropriateAuthentication if no TLS session has been established and there is no other external authentication source, or if the server did not request client credentials during TLS.

tls, ldap, security

normative-requirement §3.2 MUST

After receiving a success response to Start TLS, the client MUST either begin a TLS negotiation or close the connection; it will send TLS Record Protocol PDUs directly over the underlying TCP connection.

tls, ldap

normative-requirement §3.4 MUST

After TLS is established, both parties MUST individually decide whether to continue based on the privacy level achieved; if insufficient, they SHOULD gracefully close the TLS connection immediately.

tls, ldap, security

normative-requirement §4.1 MUST

Before closing a TLS connection, the client MUST either wait for any outstanding LDAP operations to complete or explicitly abandon them.

tls, ldap

normative-requirement §5.2 MUST

Closure of the TLS connection MUST cause the LDAP association to move to an anonymous authentication and authorization state, regardless of prior TLS or pre-TLS state.

tls, ldap, security

normative-requirement §5.1.2.3 MUST

For either form of SASL EXTERNAL assertion, the server MUST verify that the client's TLS authentication identity is permitted to map to the asserted authorization identity, and MUST reject the Bind with invalidCredentials if not.

tls, ldap, security

normative-requirement §2.3 MUST

If the server does not support TLS, it MUST set resultCode to protocolError or referral; if it returns referral, it MUST include an actual referral value in the result.

tls, ldap

normative-requirement §3.1 MUST

If the server requires TLS before a particular operation and the client has not established TLS, the server MUST reject that operation with confidentialityRequired or strongAuthRequired.

tls, ldap, security

normative-requirement §3.6 MUST

The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message to prevent man-in-the-middle attacks.

tls, ldap, security, pkix

normative-requirement §3.1 MUST NOT

The client MUST NOT send a Start TLS request if TLS is currently established on the connection, during a multi-stage SASL negotiation, or if there are any outstanding LDAP operations.

tls, ldap

normative-requirement §2.1 MUST NOT

The client MUST NOT send any PDUs on the connection after transmitting a Start TLS extended request until it receives the Start TLS extended response.

tls, ldap

normative-requirement §3.7 MUST

The client MUST refresh any cached server capabilities information (e.g. root DSE) upon TLS session establishment to protect against active-intermediary attacks that may have altered pre-TLS capability data.

tls, ldap, security

normative-requirement §3.6 MUST

The client MUST use the server hostname it used to open the LDAP connection for certificate identity comparison and MUST NOT use the server's canonical DNS name or any other derived form of name.

tls, ldap, security, pkix

normative-requirement §2.3 MUST

The server MUST return operationsError if the client violates any of the Start TLS sequencing requirements (TLS already active, during SASL negotiation, or outstanding operations exist).

tls, ldap

normative-requirement §5.1.1 MUST

Upon TLS connection establishment, any previously established authentication and authorization identities MUST remain in force, including anonymous state, even if the server requests client authentication via TLS.

tls, ldap, security

normative-requirement §2.1 MUST

When a Start TLS extended request is made, the server MUST return an LDAP PDU containing a Start TLS extended response, and that response MUST contain a responseName set to the same OID as in the request.

tls, ldap

protocol-element §2.3

A Start TLS failure resultCode is one of: operationsError (sequencing violation, e.g. TLS already established), protocolError (TLS not supported or bad PDU), referral (try another server), or unavailable (TLS error or server shutting down).

tls, ldap

protocol-element §3.6

Certificate identity matching rules: if a subjectAltName dNSName extension is present it SHOULD be used; matching is case-insensitive; the '*' wildcard applies only to the left-most name component (e.g. *.bar.com matches a.bar.com but not bar.com).

tls, pkix, ldap

protocol-element §5.1.2.2

Explicit authorization identity assertion: after TLS establishment, a client invokes SASL EXTERNAL Bind WITH the credentials octet string constructed as documented in RFC 2829 section 9.

tls, ldap, security

protocol-element §5.1.2.1

Implicit authorization identity assertion: after TLS establishment, a client invokes SASL EXTERNAL Bind WITHOUT the optional credentials octet string; the server derives authorization identity from TLS credentials per local policy.

tls, ldap, security

protocol-element §2.1

The Start TLS operation is identified by OID 1.3.6.1.4.1.1466.20037, transmitted as an LDAP ExtendedRequest with requestName set to that OID and no requestValue.

tls, ldap

security-consideration §6

An active-intermediary attacker can remove the Start TLS extended operation from the supportedExtension attribute of the root DSE, so both parties SHOULD independently ascertain the security level achieved after TLS establishment and before use, since negotiation may have been downgraded to plaintext.

tls, ldap, security

security-consideration §6

TLS does not provide confidentiality of data stored on the directory server, nor does it protect data from server administrators; it only protects operations and data in transit over the LDAP association.

tls, ldap, security, privacy

state-machine §4.1

Graceful TLS closure: initiator sends closure alert and MUST discard incoming TLS messages until it receives a closure alert, then ceases TLS PDUs and MAY resume LDAP. The other party MUST immediately transmit a closure alert upon receipt and then ceases TLS PDUs.

tls, ldap

wire-format §2.1

ExtendedRequest is APPLICATION 23, a SEQUENCE containing requestName [0] LDAPOID and optional requestValue [1] OCTET STRING. For Start TLS, requestValue is absent.

tls, ldap

wire-format §2.1

ExtendedResponse is APPLICATION 24, a SEQUENCE containing COMPONENTS OF LDAPResult, optional responseName [10] LDAPOID, and optional response [11] OCTET STRING. For Start TLS, response is absent and responseName MUST echo the request OID.

tls, ldap