Re: userPassword question

[Helmut.Volpers@mch.sni.de (Helmut Volpers)]

Ellen Stokes wrote:

> Perhaps I'm missing something here...
> Given that interoperability is important, why couldn't the server
> take the responsibility to store the userPassword encrypted and
> decrypt upon read, for example.  This preserves the protocol on
> the wire for interoperability and allows the userPassword to continue
> to be used while not being visible in the directory by anyone 'just browsing'.
> Ellen

I think Ellen is totally right, for a lot of reasons Passwords should go decrypted
over the wire.That means a server can encrypt a password but the server should be
able to decrypt
it again. The Access control can be set that nobody is allowed to read a password,

but it should be possible to replicate passwords between servers. The mechanism to

encrypt over the wire is TLS or for the bind CRAM MD5 for example.

Helmut

>
>
> At 09:10 PM 7/28/98 +0100, Mark Wahl wrote:
> >
> >> 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.
> >


begin:          vcard
fn:             Helmut  Volpers
n:              Volpers;Helmut 
adr:            Otto-Hahn-Ring 6;;;Munich;;81730;Germany
email;internet: Helmut.Volpers@mch.sni.de
title:          Directory Server Architect
tel;work:       +49-89-63646713
tel;fax:        +49-89-63645860
tel;home:       +49-89-1576588
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard