The obvious security consideration is that a client which does:
StartTLS+simple
and a client which does
simple+StartTLS
would (assuming both provided the same credentials and the negotiated
the same security layers, association state diagram were followed)
achieve the same apparent authorization state and protection levels when,
in fact, the latter approach is prone to a number of obvious attacks.
For the life of me, I cannot imagine why a client would do
simple+StartTLS+modify
or even
simple+StartTLS+search-for-user-application-objects
If the exchanged information is sensitive enough to warrant starting TLS,
then it follows that password which provides access to that
information is
equally sensitive and should be protected by TLS.
It's my opinion that the RFC 2830, section 5.1.1 absolute
imperative is inappropriate and actually in conflict with section 3.1.
Authorization state diagram aside (its not normative), if a client does
simple+StartTLS+X, the server is free, per section 3.1, to return
strongAuthRequired for X. And if 3.1 isn't enough, please consider
access and administrative control models behavior is a local matter and
servers are free to return security codes as necessary to implement
the model they support. Also, nothing in the LDAP TS should be viewed
as precluding from lowering the effective access rights or otherwise
placing restrictions upon clients for this or any other reason.
It is not only reasonable that servers treat StartTLS+simple differently
than simple+StartTLS, it makes good sense from a security perspective. I
believe that the OpenLDAP behavior (which is policy driven) of forcing
the
session to anonymous upon StartTLS has significantly improved the
security
of the Internet. There are a lot less clients doing simple+StartTLS now
and that is, IMO, a good thing.