Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
draft-ietf-ldapbis-authmeth-19

[Ballot discuss]
Please add a brief discussion of client certificate identity handling
  to the paragraph that talks about client authentication in section 6.2.
  If the client provides a valid user certificate, what might cause the
  implementation to reject the TLS negotiation?

IANA Comments:
Upon approval of this document the IANA will update the reference to be this document in the ldap-parameters registry for the StartTLS (1.3.6.1.4.1.1466.20037) extended operation.  This update will take place in the following registry:
http://www.iana.org/assignments/ldap-parameters

[Ballot discuss]
Can a client depend on being able to query the supported mechanisms
attributed after authentication to see if the list was modified by an
attacker?  If not, please document the possibility of a downgrade
attack in the security considerations section.  If so, please
explicitly note this.

Section 5 implies that a sasl security layer can be removed.  This is
inconsistent with current thinking in the SASL working group.  Please
remove this implication.

[Ballot comment]
Please consider removing the reference to RFC 2401 or 4301 from this
document's discussion of SASL external.  I don't think that IPsec
implementations tend to provide the identity information that SASL
external would need and so I believe this reference is at best
misleading.

[Ballot discuss]
Please include the fact that this document will Obsolete RFCs 2251, 2829,
  and 2830 in the Abstract.

  I am surprised by the selection of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA as
  the mandatory-to-implement TLS ciphersuite.  TLS 1.1 (RFC 4346)
  requires TLS_RSA_WITH_3DES_EDE_CBC_SHA.

  Section 3.3 says:
  >
  > Ciphersuites vulnerable to man-in-the-middle attacks SHOULD NOT be
  > used to protect passwords or sensitive data, unless the network
  > configuration is such that the danger of a man-in-the-middle
  > attack is tolerable.
  >
  I am concerned with the very subjective nature of "tolerable."  Some
  people can tolerate more pain than others.  Please change this to
  "negligible."  This term, while still subjective, has a more
  appropriate connotation.

  Please add a brief discussion of client certificate identity handling
  to the paragraph that talks about client authentication in section 6.2.
  If the client provides a valid user certificate, what might cause the
  implementation to reject the TLS negotiation?

[Ballot discuss]
(raised by Spencer Dawkins in Gen-ART review)

6.2. StartTLS Security Considerations

  Clients SHOULD by default either warn the user when the security
  level achieved does not provide an acceptable level of data
  confidentiality and/or data integrity protection, or be configured
  to refuse to proceed without an acceptable level of security.

It seemed odd that this is a SHOULD (when is it appropriate to continue with unacceptable confidentiality/integrity protection without either warning the user or refusing to proceed?).