Re: TLS renotiation

Howard,

Our security expert at Sun consider that the attack could be applied  
to LDAP, although it will be more complex to achieve for all the good  
reasons you've outline (session-oriented, with explicit authentication  
attached to a session, and is a record-oriented ASN.1 encoded protocol  
with precisely defined message structure).
The renegotiation in the attack is as far as I understand, driven by  
the man in the middle, and so even though OpenLDAP slapd never request  
the renegociation, it is still subject to the attack.

My 2 cents.

Ludovic.

On Nov 8, 2009, at 11:04 AM, Howard Chu wrote:

> Dieter Kluenter wrote:
>> Hi,
>> I just wonder weather LDAP and in particular OpenLDAP is affected by
>> TLS client auth renegotiation, as described
>> http://extendedsubset.com/?p=8
>> and the fix
>> http://isc.sans.org/diary.html?storyid=7543
>
> No. These attacks are specific to HTTP; they are effective because  
> HTTP is
> inherently stateless, lacks an explicit Authentication operation in  
> its
> protocol spec, and is a line-oriented plaintext protocol with mostly  
> ad hoc
> structure. Since LDAP is inherently session-oriented, with explicit
> authentication attached to a session, and is a record-oriented ASN.1  
> encoded
> protocol with precisely defined message structure, this stuff  
> doesn't apply.
>
> There may be other plaintext protocols that are similarly affected,  
> though I
> tend to doubt it. The majority of other useful, widely deployed  
> plaintext
> protocols are session-oriented...
>
> The PDF document outlines 3 vulnerability scenarios.
>
> In the first case, the problem is that an HTTP server might be serving
> documents from multiple security domains, and some may require  
> certificate
> authentication while others don't, and the server won't know what is  
> required
> until it has parsed the HTTP request. Because HTTP is stateless and  
> the client
> has simply issued a GET request, the certificate authentication has  
> to occur
> implicitly via a renegotiation of TLS session and be applied  
> retroactively to
> the request.
>
> LDAP never applies authentication retroactively to a session. In  
> LDAP, while
> you are allowed to renegotiate TLS in the middle of an LDAP session,  
> there is
> no actual reason to do so, and OpenLDAP slapd certainly never  
> requests it. If
> a client were to do a renegotiate to provide a new client cert, it  
> still
> wouldn't affect the LDAP session until a new LDAP Bind with SASL/ 
> EXTERNAL was
> performed, and LDAP Bind is a hard delimiter - nothing sent before  
> the Bind
> request can cause a response after the request. No session state can  
> straddle
> a Bind. Therefore you can't perform privilege escalation attacks  
> like this in
> LDAP.
>
> In the second case, differing crypto requirements - in OpenLDAP this  
> can't
> arise because cipher suite selection is global to the server, not  
> dependent on
> request context. ACLs may require a particular strength before  
> allowing access
> to a resource, but slapd simply denies the request in that case, it  
> doesn't
> try to automagically renegotiate stronger crypto with the client.  
> (Note that
> the PDF recommends making cipher suite configuration global in the  
> HTTP server
> as well, to mitigate this attack. Duh.)
>
> As for the Man in the Middle aspect, this vulnerability exists  
> because HTTP is
> a simple text line-oriented protocol, without real record  
> boundaries. LDAP is
> based on ASN.1, where each message has an explicit length encoded in  
> the
> protocol. You can't just pre-inject a bunch of data and splice a  
> valid LDAP
> request onto the end of it, the result will not be a valid LDAP  
> request. slapd
> will get a parsing error when decoding such an attempt, and will  
> simply drop
> the connection as it does for any improperly encoded messages it  
> receives.
>
> -- 
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/

---
Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Manager            Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~