Re: userPassword question

[Mark Wahl <M.Wahl@INNOSOFT.COM>]

> Isn't it a violation of RFC 2256 to have the value of the userPassword
> attribute encrypted in a way that is visible to the protocol?  Or is my
> inexperience with LDAP showing?

RFC 2256 states for the userPassword attribute:

   Passwords are stored using an Octet String syntax and are not
   encrypted. 

An application which wishes to store an encrypted password SHOULD use an
attribute description distinct from "userPassword".  Reusing userPassword
for another syntax without preserving its semantics would break 
interoperability.  One possible approach is to define a new attribute
type for each encryption mechanism, e.g. unixEncryptedPassword and 
lanManEncryptedPassword.  However, this approach would mean that an application
could not set a password even if it was protected by an TLS connection.  
Another approach is to define an attribute subtype from userpassword, either
with a different type name or using an option, e.g., userPassword;crypt-lanman
and userPassword;crypt-unix.  The "crypt" option would need to be 
defined by an standards-track RFC to specify the desired behavior on a 
modification, e.g. is each option treated independently, or does the server
itself ensure that correct password hashes are generated?

Mark Wahl, Directory Product Architect
Innosoft International Inc.