Re: DBIS - new IETF drafts

On 10/01/2014 14:15, Luke Howard wrote:
>>> Every LDAP-aware client system that I have worked with can use the
>>> bind operation as a means to validate passwords, so the only
>>> possible excuse for exporting hashes is temporary support of
>>> migrating systems. If you only allow the export of hashes that are
>>> actually needed by the old non-LDAP systems then at least you are
>>> not making matters worse than they were before the migration.
>> Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords?  If it can be done server-side there'll be no problem here and we need never expose the hashes to clients.
> Active Directory cannot.
>
> -- Luke

Thanks Luke.  Everywhere I have seen UNIX accounts deployed on AD, 
Kerberos password authentication has been used, so in those places it 
would not be an issue.  However, I cannot possibly know how many people 
out there rely on CRYPT hashes in AD attributes, and I'm not about to 
cut off the possibly of them migrating to DBIS.  CRYPT will therefore 
have to remain as an option, although I'm perfectly happy to put 
stronger wording around it.  So far I have written:

    While a DUA MAY implement any authentication password scheme
    supported by the DSA, it MUST support the CRYPT scheme for backwards
    compatibility, which is an implementation of the traditional UNIX
    crypt algorithm.  However, it is RECOMMENDED that a more secure
    scheme is used.

and ...

    Passwd and group database entries contain encrypted passwords and
    SHOULD be transmitted securely when transferred between DSA and DUA
    to prevent eavesdropping.  A DUA SHOULD NOT allow a user to see any
    encrypted passwords except they MAY see the password on their own
    posixUserAccount entry in encrypted form.

Open to suggestions on how to reword this.

Best regards,
Mark.