RE: please publish ldap password policy draft

[Jim Sermersheim <JIMSE@novell.com>]

Bob,

<snip>
>>
>> Several 3-tier applications are using LDAP to perform password based
>> authentication. This can be the case of an web-ldap gateway, an
>> Mail server, an
>> FTP server...or the LDAP Pluggable Authentication Module (PAM).
>> It's true that opening a connection for each authentication doesn't really
>> scale.
>> Many of these applications open one connection, authenticate
>> themselves and
>> just check the user password using a compare operation using the
>> User DN and
>> the user password. The compare operation is much faster because
>> you don't have
>> to perform extra checking and computing that the bind operation has to do.
>>
>
>Thanks for the reply.  I do understand that this architecture will greatly
>improve performance of applications that maintain a connection to the LDAP
>server, such as an what you mentioned above.  My point is that I don't think
>LDAP PAM is a good example of this.  Most examples you provied above are
>servers (which can easily maintian the connection to the LDAP server.)  I've
>never seen an implementation of PAM that works like a server (though it's
>certianly possible.)

Good point, I had imagined a future where a PAM redirector *could* work this way.  For now it looks like it's more confusing than it's worth, we can take it out of the next version.

>> >
>> > Am I correct in understanding that you don't examine all password policy
>> > rules for a compare operation?  For example, suppose that the
>> entry has a
>> > login time of day restriction (defind outside the scope of this schema.)
>>
>> This is out of the scope of this draft. We're thinking about such
>> services but
>> they are not dealing with passwords. So they should appear in a separate
>> document.
>>
>
>Since 12.5 starts out by saying this feature is useful for authentication
>redirectors, I'm a bit concerned that the redirector may authenticate a user
>because a compare succeeded when other policy rules would have caused a
>failure.  I guess I'm concerned about promoting this type of architecture
>for those reasons.  But this is a subjective view.

I think we could state something in the draft like: "implementors should be aware that other authentication related policies (specifically login policies) could also be in force and that those policies may add additional behavior or restrictions to this operation".

We talked about including things like a allowed login time map, whether login was dis/enabled and so on, but decided it was removed enough from 'passwords' that it deserved its own draft. When that draft is written, this one will definitely reference it here.

>> > How should zero length password strings be treated?  In a bind
>> operation the
>> > null string is a special syntax that means bind anonymously.
>> What does it
>> > mean for a compare?
>>
>> It doesn't mean anything. You cannot compare with zero length
>> password. The
>> client should not call the compare operation if it
>> doesn't want to perform authentication.
>
>As one example, RFC 2256 defines userPassword to be an Octet String.  And if
>I am not mistaken, that means that the userPassword attribute can have zero
>length.  Thus a compare operation of a zero length string against a zero
>length userPassword attribute should succeed, no?

This is a problem which needs to be addressed somewhere. I don't feel like this is *really* the right place to do it because this document only means to say "if you're going to allow the compare operation to be used on the userPassword, you better be aware of and follow these password policies", it wasn't meant to patch this little problem. But... I guess since the definition of userPassword doesn't prevent one from storing a 0 length value, and since this is the only document that discusses the compare operation on the userPassword value, it could include a note to server implementors to not allow comparisons of empty values. Any other suggestions?

Jim