LDAP and the TLS renegotiation vulnerabilities

Over the last few days I took some time to study into how LDAP is  
impacted by the TLS renegotiation vulnerability.  This note discusses  
my preliminary findings.


Suggested reading:
   http://extendedsubset.com/?p=8
   http://extendedsubset.com/Renegotiating_TLS.pdf
   http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt


Discussion:

First, disabling TLS renegotiations in the server prevents all of  
these attacks discussed below.  Unfortunately, doing this will have  
some negative impacts.  But it might be best short term solution, but  
it's not without some issues and may be inappropriate for some  
deployments (such as those relying on long-lived TLS protected LDAP  
sessions).  Assuming TLS renegotiations are enabled in the server....

The most significant impact LDAP is in servers supporting the non-
standard "implicit bind" (or "auto bind") feature.  This feature,  
which dates back to LDAPv2 and SSL days, provides for use of client  
certificates to establish the client's identity without a requirement  
to perform a LDAP Bind operation.  That is, the client would simply  
assert its certificate as part of the TLS handshake and the server  
would, if the certificate was acceptable, process all future  
operations as the identity it associates with the certificate.  The  
attacker can use the TLS renegotiation vulnerability to cause the  
server to process any request, including update requests, as the  
identity associated with the client's certificate.   Aside from  
disabling TLS renegotiating in the server, disabling LDAP 'implicit  
bind' feature prevents this.  There is little excuse for clients not  
to be doing StartTLS + LDAP SASL EXTERNAL Bind.

A milder impact to LDAP is in clients which do:
        StartTLS
        ++ establish TLS, assert certificate
        + LDAP SASL EXTERNAL Bind
        + subsequent LDAP requests

Because the LDAP SASL EXTERNAL BIND requests tend to have a  
predictable encoding and the TLS vulnerabilities allow for prefixing  
arbitrary data, it is possible for the attacker to construct an LDAP  
Simple "anonymous" Bind which eclipses the LDAP SASL EXTERNAL BIND  
and, hence, causes the subsequent LDAP requests to be processed  
"anonymously" instead of as the identity associated with the client's  
certificate.  This could lead to the client thinking some resources  
were absent when they actually exist.   There are variants of this  
scenario but this seems to be the most interesting.  Aside from  
disabling TLS renegotiating in the server, this particular attack can  
be mitigated by the client by initiating and completing LDAP search  
operation, such as as a read of the Root DSE, after the TLS handshake  
but before initiating the LDAP SASL EXTERNAL Bind request.

There may well be other possible attacks.


Recommendations:

Disable TLS renegotiations in the server.

Disable 'implicit bind' in the server.   Clients should use LDAPv3's  
StartTLS + SASL EXTERNAL instead.

Clients providing client certificates in TLS handshakes might consider  
doing an LDAP Search before the LDAP SASL EXTERNAL Bind as discussed  
above.

Implement support in clients and servers for the TLS protocol fix  
(draft-rescorla-tls-renegotiation).  Early implementations of this fix  
in commonly used TLS libraries are already emerging.


Summary:

The TLS renegotiation vulnerability can be used to mount attacks upon  
LDAP applications, especially those relying on non-standard LDAP  
'implicit' binds.  A fix to TLS (draft-rescorla-tls-renegotiation) is  
in the works and LDAP vendors should start work on supporting it.  By  
following the above recommendations, the impact of the TLS  
renegotiation issues upon LDAP can be minimized.

-- Kurt

NOTE:  I have purposely left off key details on how to mount such  
attacks to slow unskilled attackers.
_______________________________________________
Ldapext mailing list
Ldapext@...
https://www.ietf.org/mailman/listinfo/ldapext