Skip to main content

Appendix B. Summary of Changes

This appendix is non-normative.

This appendix summarizes substantive changes made to RFC 2251, RFC 2829 and RFC 2830. In addition to the specific changes detailed below, the reader of this document should be aware that numerous general editorial changes have been made to the original content from the source documents. These changes include the following:

  • The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2, RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was combined into a single document.

  • The combined material was substantially reorganized and edited to group related subjects, improve the document flow, and clarify intent.

  • Changes were made throughout the text to align with definitions of LDAP protocol layers and IETF security terminology.

  • Substantial updates and additions were made to security considerations from both documents based on current operational experience.

B.1. Changes Made to RFC 2251​

This section summarizes the substantive changes made to Sections 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional substantive changes to Section 4.2.1 of RFC 2251 are also documented in [RFC4511].

B.1.1. Section 4.2.1 ("Sequencing of the Bind Request")​

  • Paragraph 1: Removed the sentence, "If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection". The Unbind operation still permits this behavior, but it is not documented explicitly.

  • Clarified that the session is moved to an anonymous state upon receipt of the BindRequest PDU and that it is only moved to a non- anonymous state if and when the Bind request is successful.

B.1.2. Section 4.2.2 ("Authentication and Other Security Services")​

  • RFC 2251 states that anonymous authentication MUST be performed using the simple bind method. This specification defines the anonymous authentication mechanism of the simple bind method and requires all conforming implementations to support it. Other authentication mechanisms producing anonymous authentication and authorization state may also be implemented and used by conforming implementations.

B.2. Changes Made to RFC 2829​

This section summarizes the substantive changes made to RFC 2829.

B.2.1. Section 4 ("Required security mechanisms")​

  • The name/password authentication mechanism (see Section B.2.5 below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as LDAP's mandatory-to-implement password-based authentication mechanism. Implementations are encouraged to continue supporting SASL DIGEST-MD5 [DIGEST-MD5].

B.2.2. Section 5.1 ("Anonymous authentication procedure")​

  • Clarified that anonymous authentication involves a name value of zero length and a password value of zero length. The unauthenticated authentication mechanism was added to handle simple Bind requests involving a name value with a non-zero length and a password value of zero length.

B.2.3. Section 6 ("Password-based authentication")​

  • See Section B.2.1.

B.2.4. Section 6.1 ("Digest authentication")​

  • As the SASL-DIGEST-MD5 mechanism is no longer mandatory to implement, this section is now historical and was not included in this document. RFC 2829, Section 6.1, continues to document the SASL DIGEST-MD5 authentication mechanism.

B.2.5. Section 6.2 ("'simple' authentication choice under TLS​

    encryption")

  • Renamed the "simple" authentication mechanism to the name/password authentication mechanism to better describe it.

  • The use of TLS was generalized to align with definitions of LDAP protocol layers. TLS establishment is now discussed as an independent subject and is generalized for use with all authentication mechanisms and other security layers.

  • Removed the implication that the userPassword attribute is the sole location for storage of password values to be used in authentication. There is no longer any implied requirement for how or where passwords are stored at the server for use in authentication.

B.2.6. Section 6.3 ("Other authentication choices with TLS")​

  • See Section B.2.5.

B.2.7. Section 7.1 ("Certificate-based authentication with TLS")​

  • See Section B.2.5.

B.2.8. Section 8 ("Other mechanisms")​

  • All SASL authentication mechanisms are explicitly allowed within LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN mechanisms are no longer precluded from use within LDAP.

B.2.9. Section 9 ("Authorization Identity")​

  • Specified matching rules for dnAuthzId and uAuthzId values. In particular, the DN value in the dnAuthzId form must be matched using DN matching rules, and the uAuthzId value MUST be prepared using SASLprep rules before being compared octet-wise.

  • Clarified that uAuthzId values should not be assumed to be globally unique.

B.2.10. Section 10 ("TLS Ciphersuites")​

  • TLS ciphersuite recommendations are no longer included in this specification. Implementations must now support the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.

  • Clarified that anonymous authentication involves a name value of zero length and a password value of zero length. The unauthenticated authentication mechanism was added to handle simple Bind requests involving a name value with a non-zero length and a password value of zero length.

B.3. Changes Made to RFC 2830​

This section summarizes the substantive changes made to Sections 3 and 5 of RFC 2830. Readers should consult [RFC4511] for summaries of changes to other sections.

B.3.1. Section 3.6 ("Server Identity Check")​

  • Substantially updated the server identity check algorithm to ensure that it is complete and robust. In particular, the use of all relevant values in the subjectAltName and the subjectName fields are covered by the algorithm and matching rules are specified for each type of value. Mapped (derived) forms of the server identity may now be used when the mapping is performed in a secure fashion.

B.3.2. Section 3.7 ("Refresh of Server Capabilities Information")​

  • Clients are no longer required to always refresh information about server capabilities following TLS establishment. This is to allow for situations where this information was obtained through a secure mechanism.

B.3.3. Section 5 ("Effects of TLS on a Client's Authorization​

    Identity")
  • Establishing a TLS layer on an LDAP session may now cause the authorization state of the LDAP session to change.

B.3.4. Section 5.2 ("TLS Connection Closure Effects")​

  • Closing a TLS layer on an LDAP session changes the authentication and authorization state of the LDAP session based on local policy. Specifically, this means that implementations are not required to change the authentication and authorization states to anonymous upon TLS closure.

  • Replaced references to RFC 2401 with RFC 4301.