|
Disallowing them completely may break some current client and server implementations. I remember some people (maybe Mark Smith) from Netscape saying that they use the mechanism as some way of voluntary auditing or some such.
I prefer the compromise solution brought up in yesterday's meeting where part of the note is moved into the main body of the document with a pointer to the security considerations which contains the reasons why.
Jim >>> John McMeeking <jmcmeek@us.ibm.com> 11/12/03 8:51:21 AM >>> In my limited experience with RFCs I haven't had to deal with requirements like "MUST by default do ..." or "default configuration MUST do ...". My first reaction is to read this as if the "default" wording was missing. But upon further thought... I have no problem with disallowing unauthenticated binds as proposed, or even disallowing them completely. John McMeeking Chris Newman < Chris.Newman@Sun.CO To: ietf-ldapbis@OpenLDAP.org M> cc: Sent by: Subject: unauthenticated bind owner-ietf-ldapbis@O penLDAP.org 11/11/2003 01:43 PM LDAP is often used as the authentication store for other services (e.g., services). These services use LDAP to validate passwords. I have seen many cases where shipping software does a simple bind to test if a user's password is valid and due to unauthenticated bind, this will always succeed with an empty password and allow an attacker to access every account. The example code in Tim Howe's book for exactly this purpose has exactly this bug, so we will never get rid of this security hole in LDAP by fixing the client code because we'll always have new client code with this bug. The only way to fix this LDAP security hole properly is to disallow unauthenticated bind on the server (I have no problem with anonymous bind). Currently, this text is buried in the security considerations section of the authmeth draft with a fairly weak "SHOULD". The requirement should be in section 6.1 of authmeth and should be a "MUST by default reject authentication requests that have a DN with an empty password". - Chris |