Re: please publish ldap password policy draft

[Jim Sermersheim <JIMSE@novell.com>]

>>> "Kurt D. Zeilenga" <kurt@openldap.org> 10/21/99 9:06:43 AM >>>

>This draft proposes changes the behavior of userPassword attribute
>which are incompatible with the RFC2256 defined schema rules:
>
>  5.36. userPassword   
>    ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch  
>      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
>   Passwords are stored using an Octet String syntax and are not
>   encrypted.
>
>a) compare must use octetStringMatch

This draft avoids talking about how the actual comparison takes place. It only states that *if* a comparison happens, it better take the password policy information into account and behave accordingly.

>b) servers cannot encrypt (or hash) the password and store
>   it in userPassword.

I don't want to use this document to re-hash (he he) the whole 'syntax of userPassword' discussion we've had twice now. Suffice it to say, this draft was written in a way that supports the de facto standard way some servers are currently storing values of userPassword. If a server does not support storing userPassword as described in RFC2307, it should only allow the value of 'CLEARTEXT' to be set in the pwdDefaultStorageScheme attribute.

When a draft is submitted, which defines a 'crypt' attribute type option, and formalizes a standard way for LDAP servers to store hashed or encrypted passwords, this document will be updated to take that into account.

>The draft relies on LDAPv3 mechanisms (controls).  The
>draft, however, does not state that any protocol restrictions
>exist.  If LDAPv2 is to be supported, the document should state
>how a server should respond with the client attempts to bind
>or is bound using LDAPv2.

...being discussed on another thread...

>The draft uses results not allowed by RFC2251.  In particular,
>constraintViolation is not allowed in a bindResponse.

We discussed this and it was decided that in this case, the user was breaking a constraint set by the password policy. On the other hand, constraint violation is grouped with the attribute errors, not the security errors...

>Editing issues:
>  The draft should not be written in terms of the LDAP C API draft.
>  Please use names defined by RFC2251 instead of LDAP C API defines.
>	ie: use constraintViolation not LDAP_CONSTRAINT_VIOLATION

I agree, we should change them as you suggest.

Jim